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1.0  INTRODUCTION 


The  major  expenses  in  computer  systems  at  present  and  in  the  future  are 
in  software  [1,2].  While  the  cost  of  hardware  is  dropping  rapidly  due  to  an 
order-of -magnitude  improvement  in  the  hardware  price /performance  ratio  every 
ten  years,  software  productivity  improves  only  slowly.  Thus,  the  cost  of 
software  relative  to  hardware  is  increasing.  Estimates  of  this  overall  • 
cost  of  software  development  and  maintenance  in  the  United  States  range  from 
$15  to  $25  billion.  By  1985,  computer  software  expenses  are  estimated  to  be 
about  90  percent  of  the  total  system  cost  [1,2].  In  Fact,  on  one  existing 
program,  the  World  Wide  Military  Command  and  Control  System,  this  percent  is 
already  in  that  vicinity  with  $722  million  for  software  to  $50-$100  million 
for  hardware  [3], 

These  staggering  figures  have  stimulated  great  efforts  in  recent  years 
to  study  software.  Yet,  the  cost  of  developing  large-scale  software  systems 
has  become  unacceptably  high.  The  term  large-scale  software  as  used  in  this 
report  refers  to  those  programs  in  excess  of  30,000  lines  of  code  requiring 
a  team  effort  to  produce  and  at  least  one  year  to  implement.  Such  systems 
are  becoming  increasingly  important  in  a  variety  of  applications  including 
military  weapon  systems,  vehicle  control  systems,  industrial  operations  and 
process  control  systems,  communication  systems,  and  the  like.  Because  these 
systems  are  inherently  complex,  they  require  a  great  deal  of  time,  effort, 
and  cost  to  develop. 

Current  experience  in  developing  these  large-scale  software  systems  has 
been  discouraging.  Most  software  development  projects  are  unsuccessful  in 
terms  of  specification,  time,  and  cost  [1],  An  examination  of  the  software's 
life  cycle  was  conducted  by  Boehm  [2]  to  analyze  the  software  phases.  The 
results  of  his  study  are  illustrated  in  Figure  1.  His  results  indicate  that 
the  cost  of  maintenance  is  40  percent  of  the  total  software  cost.  More 
recent  studies  have  confirmed  the  high  cost  of  maintenance  [4-7].  Figure  2 
is  a  more  recent  analysis  of  the  software  phases  [5],  The  results  of  this 
analysis  indicate  that  the  cost  of  maintenance  is  67  percent  of  the  total 
software  cost.  Other  studies  have  reported  similar  figures  for  the  cost  of 
maintenance.  For  example,  it  has  been  estimated  that  up  to  80  percent  of 
IBM's  application  development  resources  are  devoted  to  maintenance  [6], 
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Figure  2.  A  more  recent  survey  of  large-scale 
program  life  cycle  cost  [5]. 
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Similar  figures  were  also  reported  by  Elshoff  [7],  who  indicated  that  75  per¬ 
cent  of  General  Motor's  commercial  software  effort  was  spent  on  maintenance. 
With  maintenance  costs  so  high,  it  would  appear  that  this  phase  should  be 
analyzed  in  an  effort  to  help  reduce  the  total  software  cost. 

When  one  attempts  to  discuss  software  maintenance,  it  becomes  apparent 
that  the  term  is  not  well  defined.  Software  maintenance  is  a  very  broad 
activity  that  includes  error  corrections,  enhancements  of  capability,  deletion 
of  obsolete  capabilities  and  minor  changes  in  mission  requirements  [8,13]. 
Optimization  is  also  considered  as  a  form  of  maintenance  requiring  the  modifi¬ 
cation  of  code  within  individual  modules,  or  possibly  the  structure  of  the 
complete  system  in  order  to  improve  its  efficiency  [14]. 

The  maintainability  of  a  software  system  is  a  measure  of  the  ease  of 
performing  maintenance  to  the  software  system,  and  all  maintenance  activities 
require  making  modifications  to  the  system.  The  effect  of  a  modification  to 
a  software  system  may  not  be  local  to  the  location  of  the  modification,  but 
may  also  affect  other  portions  of  the  system.  This- means  a  ripple  effect 
existing  from  the  location  of  the  modification  to  the  other  parts  of  the 
system  that  are  affected  by  the  modification  [8,15-18].  One  aspect  of  this 
ripple  effect  is  logical  or  functional  in  nature.  In  our  other  report  [18], 
a  maintenance  tool  for  estimating  logical  ripple  effect  for  any  program  modi¬ 
fication  was  developed.  This  estimation  of  logical  ripple  effect  is  accom- 

4 

plished  by  performing  a  static  analysis  to  characterize  the  program.  The 
program  is  characterized  by  its  control  variables,  data  variables,  and  proce¬ 
dure  calls.  The  tool  then  associates  with  each  program  change  a  modification 
to  a  group  of  decisions  which  characterizes  a  portion  of  the  program's  speci¬ 
fication.  Modification  to  a  group  of  decisions  requires  physical  changes  to 
module  variables  which  must  reflect  those  decisions.  A  change  to  a  variable 
defines  a  primary  source  from  which  inconsistency  propagates  to  other  program 
areas.  By  knowing  the  primary  sources  involved  in  a  program  modification  and 
the  module's  characteristics,  potential  worst  logical  ripple  effect  can  be 
calculated  by  tracing  the  program  paths  over  which  inconsistencies  can  flow. 
The  development  of  this  tool  enables  maintenance  personnel  to  do  a  better  job 
by  allowing  them  to  know  the  scope  of  effect  of  a  software  modification. 


Another  aspect  of  this  ripple  effect,  which  cannot  be  handled  by  the 
logical  ripple  effect  tool  just  described,  concerns  the  performance  of  the 
system  [8,17].  During  software  maintenance,  it  is  possible  to  perform  a 
modification  to  the  system,  investigate  its  logical  ripple  effect  and  locate 
the  inconsistencies  introduced  throughout  the  program  by  the  modification. 
After  all  the  logical  corrections  have  been  made  to  the  system,  the  mainte¬ 
nance  personnel  may  conclude  that  they  have  restored  the  system  to  its 
previous  level  of  functional  correctness.  The  performance  of  the  system, 
however,  may  have  been  altered  as  a  direct  result  of  this  maintenance  activ¬ 
ity.  Since  a  large-scale  program  usually  has  both  functional  and  performance 
requirements,  the  net  result  of  the  maintenance  effort  may  be  satisfactory 
to  the  functional  requirements,  but  not  to  some  performance  requirements 
[8,17]. 

In  many  large-scale  systems,  the  violation  of  a  performance  requirement 
is  equivalent  to  a  system  error  and,  thus,  requires  further  corrective  action 
[19,20l»  Consequently,  it  is  important  in  the  maintenance  process  to  fully 
understand  the  potential  effect  of  a  modification  to  the  system  in  terms  of 
the  performance  of  the  parts  of  the  system  directly  involved  in  the  modifica¬ 
tion  as  well  as  those  that  are  affected  indirectly.  The  change  in  perfor¬ 
mance  of  these  parts  may  then  have  an  impact  on  the  performance  of  the  other 
parts  of  the  system. 

The  maintenance  process  can,  thus,  be  improved  if  maintenance  personnel 
are  supplied  with  information  enabling  them  to  incorporate  performance  con¬ 
siderations  in  their  criteria  for  selecting  the  type  and  location  of  software 
modifications  to  be  made.  This  information  is  provided  by  the  development 
of  a  maintenance  technique  for  predicting  which  performance  requirements  in 
the  system  may  be  affected  by  a  proposed  modification.  The  prediction  of 
which  performance  requirements  may  be  affected  by  a  software  modification  is 
a  difficult  task.  Due  to  the  size  and  complexity  of  design  of  many  large- 
scale  programs,  maintenance  changes  can  cause  repercussions  almost  anywhere 
throughout  the  system  [7,8,17].  Thus,  the  significance  of  this  technique 
lies  in  its  ability  to  trace  these  repercussions  and  predict  which  perfor¬ 
mance  requirements  may  be  affected. 

In  this  report  we  formalize  the  technique  outlined  in  our  previous 
reports  [8,17]  for  predicting  which  performance  requirements  in  the  system 
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may  be  affected  by  a  proposed  software  modification.  This  technique  is 
applicable  to  all  types  of  large-scale  systems  possessing  performance 
requirements  including  multiprocessing  systems. 

In  this  report  we  will  also  illustrate  how  the  technique  can  help  retest 
the  system  whether  its  performance  requirements  have  been  violated  by  the 
maintenance  effort  after  the  maintenance  changes  have  been  implemented.  The 
maintenance  technique  analyzes  the  proposed  changes  with  respect  to  the 
performance  of  the  entire  system,  and  not  just  the  local  areas  involved  in 
the  modification.  It  can  then  determine  the  performance  requirements 
affected  by  the  maintenance  change.  It  should  be  noted  that  during  the 
evaluation  of  alternative  modifications,  the  maintenance  technique  was  used 
to  predict  worst-case  effects  on  performance  of  software  modifications.  Now 
that  the  modification  has  been  completely  implemented,  the  maintenance 
technique  can  substantially  refine  its  analysis  and  determine  more  accurately 
the  performance  requirements  affected  by  the  maintenance  modifications.  This 
permits  the  identification  of  which  portions  of  the  system  must  be  retested 
to  insure  that  these  performance  requirements  have  not  been  violated.  Since 
the  maintenance  effort  must  not  violate  any  functional  or  performance 
requirements,  this  maintenance  technique  provides  a  significant  contribution 
in  determining  the  scale  of  retesting  effort  needed  to  insure  that  these 
requirements  have  not  been  violated. 

Another  very  significant  product  of  the  analysis  of  ripple  effect  from 
both  a  logical  and  performance  perspective  is  the  computation  of  a  figure-of- 
merit  for  the  complexity  of  a  proposed  program  modification.  The  figure 
presented  in  this  report  provides  a  measure  which  reflects  the  work  involved 
in  performing  maintenance  and,  thus,  provides  a  standard  for  comparison 
the  complexity  of  proposed  modifications. 

It  should  be  noted  that  the  maintenance  technique  presented  in  this 
report  is  language  independent  and  applicable  to  currently  existing  programs 
as  well  as  newly  implemented  programs  incorporating  state-of-the-art  design 
techniques.  The  technique  does  not  provide  maintenance  personnel  with  pro¬ 
posals  for  modifying  the  program.  Instead,  the  technique  is  applied  after 
the  maintenance  personnel  have  generated  a  number  of  possible  maintenance 
proposals.  A  figure -of -merit  for  the  complexity  of  modification  can  be 
computed  for  each  of  the  proposed  modifications  and  the  maintenance 
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personnel  can  then  select  the  best  modification  from  both  a  logical  and  per¬ 
formance  perspective.  The  modification  can  then  be  completely  implemented, 
and  the  changes  felt  in  other  portions  of  the  program  will  be  dealt  with  by 
analysis  of  the  ripple  effect. 

1 . 1  Review  of  Performance  Dependency  Relationships 

The  identification  of  modules  whose  performance  may  change  as  a  conse¬ 
quence  of  software  modifications  is  a  complex  task.  The  identification  is 
complicated  by  the  fact  that  performance  dependencies  often  exist  among 
modules  which  are  otherwise  functionally  and  logically  independent.  In  our 
previous  report  [17],  we  defined  several  types  of  performance  dependency 
relationships  and  provided  examples  of  each.  A  brief  summary  of  these  defi¬ 
nitions  is  given  here. 

Performance  Dependency  Relationship  (PDR) ;  A  PDR  is  defined  to  exist  from 
Module  A  to  Module  B  if  there  exists  a  change  in  Module  A  that  can  have  an 
effect  on  the  performance  of  Module  B. 

Performance  Interdependency  Relationship  (PIR):  A  PIR  is  defined  to  exist 
between  Module  A  and  Module  B  if  a  PDR  exists  from  Module  A  to  Module  B  and 
from  Module  B  to  Module  A. 

Pure  Performance  Dependency  Relationship  (PPDR) :  A  PPDR  is  defined  to  exist 
from  Module  A  to  Module  B  if  there  exists  a  change  in  performance  of  Module  A 
which  is  not  the  result  of  a  modification  to  Module  A  and  can  have  an  effect 
on  the  performance  of  Module  B. 

Pure  Performance  Interdependency  Relationship  (PPIR):  A  PPIR  is  defined  to 
exist  between  Module  A  and  Module  B  if  a  PPDR  exists  from  Module  A  to  Module  B 
and  from  Module  B  to  Module  A. 

Performance  Independent  (PI);  Two  modules  are  defined  to  be  performance 
independent  if  there  does  not  exist  a  PDR  or  PPDR  from  one  to  the  other. 

1 . 2  Review  of  Mechanisms  for  the  Propagation  of  Performance  Changes 

It  is  obvious  that  when  a  logical  or  functional  error  is  discovered  in 
the  software,  the  scope  of  effect  of  this  error  will  include  other  modules. 
Analogously,  when  a  performance  change  is  made,  the  scope  of  effect  of  the 
change  can  be  determined  by  examining  the  mechanisms  by  which  this  change 


7 


can  affect  other  modules.  In  our  previous  report  [17],  we  identified  eight 
mechanisms  which  may  exist  in  large-scale  systems  'by  which  changes  in  per¬ 
formance  as  a  consequence  of  a  software  modification  are  propagated  through¬ 
out  the  system.  These  mechanisms  are  summarized  here: 

1.2.1  Parallel  Execution 

The  first  mechanism  for  the  propagation  of  performance  changes  involves 
a  modification  during  maintenance  which  results  in  a  loss  of  parallel  execu¬ 
tion  capability.  In  the  maintenance  phase  it  is  possible  to  introduce  soft¬ 
ware  modifications  to  a  module  which  can  destroy  its  ability  to  be  executed 
with  other  modules  in  parallel.  The  maintenance  personnel  must  then  be 
aware  of  the  change  in  performance  which  will  result  from  the  loss  of  the 
parallelism.  Major  changes  in  performance  may  occur  due  to  execution  delays 
and  contention  for  resources  previously  alleviated  through  the  parallel 
execution. 

1.2.2  Shared  Resources 

Another  mechanism  for  the  propagation  of  performance  changes  is  conten¬ 
tion  for  resources  among  modules.  When  modules  are  forced  to  share 
resources,  the  time  when  each  module  requests  and  releases  common  resources 
are  important  performance  parameters.  Thus,  software  modifications  producing 
performance  changes  in  the  time  that  the  resources  are  utilized  can  have  det- 
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rimental  effects  on  the  performance  of  modules  that  must  share  the  resources. 

1.2.3  Interprocess  Communication 

Another  mechanism  for  the  propagation  of  performance  changes  involves 
communication  among  the  modules  in  the  system.  When  one  module  must  send  a 
message  to  another  module,  the  performance  of  the  module  receiving  the 
message  is  dependent  of  when  the  message  is  actually  received.  Thus, 
modifications  to  the  module  sending  the  message  that  alter  the  time  when 
the  message  is  sent  can  affect  the  performance  of  the  module  designated  to 
receive  the  message. 

1.2.4  Called  Modules 

Another  mechanism  for  the  propagation  of  performance  changes  is  the 
utilization  of  called  modules  in  the  software.  Modifications  to  modules  in 
the  maintenance  phase  can  be  divided  into  two  types.  A  bounded  modification 
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to  a  module  is  a  modification  which  does  not  alter  the  performance  of  the 
module.  An  unbounded  modification  to  a  module  is  a  modification  which  alters 
the  performance  of  the  module.  An  unbounded  modification  to  the  called 
module  will  affect  the  performance  of  all  modules  calling  it.  A  bounded 
modification  will  not  affect  the  performance  of  the  other  modules  calling  it. 

1.2.5  Shared  Data  Structures 

Another  mechanism  for  the  propagation  of  performance  changes  is  through 
the  utilization  of  shared  data  structures.  The  basic  dynamic  attributes  con¬ 
tributing  to  performance  in  this  area  are  a  module's  storage  and  retrieval 
times  for  entries  in  the  data  structures.  Factors  affecting  storage  and 
retrieval  times  vary  among  the  different  types  of  data  structures  as  well  as 
the  algorithms  utilized  to  manipulate  these  structures. 

1.2.6  Sensitivity  to  the  Rate  of  Input 

Another  mechanism  for  the  propagation  of  performance  changes  involves 
the  rate  of  input  into  a  process.  This  change  in  input  frequency  is  the 
result  of  a  changing  environment.  The  resulting  change  of  input  rate  to  the 
process  can  have  major  repercussions  in  terms  of  its  functional  and  perfor¬ 
mance  requirements.  For  example,  it  can  lead  to  saturation  and  possibly 
overflow  of  data  structures  involved  with  the  processing  of  the  input.  The 
increased  frequency  of  input  arrivals  may  also  lead  to  interruptions  in 
processing  which  can  lead  to  both  functional  and  performance  requirement 
violations . 

1.2.7  Execution  Priorities 

Another  mechanism  for  the  propagation  of  performance  changes  involves 
the  execution  priority  of  modules.  During  the  development  phase,  module 
execution  priorities  may  have  been  established  to  insure  correct  sequencing 
or  preservation  of  critical  system  performance  requirements.  The  priorities 
are  used  to  determine  the  execution  order  of  modules  capable  of  beginning 
execution  at  the  same  time.  The  priorities  may  also  be  utilized  in  the 
determination  of  whether  or  not  a  module's  execution  should  be  pre-empted 
for  that  of  a  module  with  a  higher  priority.  During  the  maintenance  phase, 
it  is  important  for  maintenance  personnel  to  recognize  the  effect  of  a  pro¬ 
posed  modification  in  respect  to  the  existing  priorities  in  the  system. 
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1.2.8  Abstractions 


Another  mechanism  for  the  propagation  of  performance  changes  is  the 
utilization  of  abstractions  in  the  software.  The  use  of  abstractions  is  a 
popular  design  tool  and  adds  to  the  maintainability,  of  the  system  by  hiding 
design  decisions.  From  the  performance  perspective  of  maintainability, 
however,  abstractions  are  "trojan  horses."  This  is  because  a  change  in  the 
implementation  of  the  abstraction  will  very  likely  affect  the  performance  of 
the  abstraction,  and,  thus,  the  performance  of  all  modules  utilizing  the 
abstraction.  This  is  a  classic  example  of  a  case  where  a  modification  to  the 
software  during  maintenance  does  not  produce  any  functional  or  logical 
changes,  but  it  does  result  in  performance  changes. 

2.0  PERFORMANCE  AND  VIRTUAL  PERFORMANCE  ATTRIBUTES 

Performance  attributes  of  a  program  are  defined  as  attributes  corres¬ 
ponding  to  measurements  of  key  portions  of  the  execution  of  the  program. 

For  example,  one  performance  attribute  of  a  module  is  its  execution  time. 
Another  is  the  utilization  for  a  particular  resource  during  the  execution 
of  the  program.  There  is  a  distinct  relationship  between  performance  attri¬ 
butes  and  the  eight  mechanisms  for  the  propagation  of  performance  changes. 

The  eight  mechanisms  operate  as  links  between  performance  attributes  of 
modules.  In  other  words,  a  change  in  a  performance  attribute  of  one  module 
can  affect  a  performance  attribute  in  another  module  via  one  of  the  eight 
mechanisms.  For  example,  let  X  represent  the  performance  attribute  corres¬ 
ponding  to  the  time  a  resource  is  seized  by  module  A.  Assume  module  B  is  in 
contention  for  the  same  resource  with  module  A  and  let  Y  represent  the  per¬ 
formance  attribute  corresponding  to  the  time  module  B  seizes  the  same 
resource.  Then  a  change  in  performance  attribute  X  can  affect  performance 
attribute  Y  via  the  shared  resources  mechanism. 

The  relationship  between  performance  attributes  and  the  eight  mechanisms 
for  the  propagation  of  performance  changes  is  illustrated  in  Figure  3,  where 
the  directed  line  labeled  with  a  mechanism  connecting  two  performance  attri¬ 
butes  indicates  a  performance  dependency  relationship  exists  between  the 
performance  attributes.  For  example,  if  performance  attribute  2  of 
Process  A  is  modified,  it  can  affect  performance  attribute  2  of  Process  B 
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We  will  now  present  fourteen  software  performance  attributes.  These 
performance  attributes  are  not  a  complete  set  of  attributes  corresponding  to 
measurements  of  the  execution  of  the  program.  Instead,  these  performance 
attributes  are  the  attributes  linked  with  the  eight  mechanisms  as  previously 
discussed.  One  way  to  state  the  performance  requirements  of  software  is 
to  express  them  in  terms  of  flows  through  the  system,  such  as  in  an  R-Net 
the  performance  attributes  being  defined  for  "alphas"  [17,21],  We  may  define 
an  R-Net  as  a  graph  that  consists  of  the  following  items: 

(1)  A  set  of  nodes  representing  processing  steps  called  "alphas". 

(2)  A  set  of  nodes  identifying  processing  conditions,  called  "OR"  nodes, 

associated  with  a  selector  variable. 

(3)  A  set  of  "AND"  nodes  identifying  "don't-care"  sequences  of  Alphas  which 
could  be  performed  in  any  sequence  or  even  in  parallel. 

(4)  A  set  of  interface  nodes  where  external  messages  are  received  or  trans¬ 
mitted  . 

(5)  A  set  of  initial  and  terminal  nodes. 

(6)  A  set  of  arcs  joining  the  nodes  in  a  legal  fashion. 

(7)  A  set  of  events  on  R-Net  Paths,  each  of  which  enables  an  R-Net  to  per¬ 

form  processing.  The  arrival  of  a  message  at  an  interface  may  also 
constitute  an  event. 

(8)  A  set  of  validation  points  used  to  uniquely  identify  paths,  and  to 
specify  where  data  are  to  be  extracted  to  test  the  process. 

The  R-Net  is  a  synthesis  of  a  set  of  paths.  Each  Alpha  is  associated 
with  two  subsets  of  data  identifiers,  representing  data  input  to  and  output 
from  the  processing  step.  The  link  between  the  functional  and  performance 
requirements  is  achieved  through  the  validation  points.  Each  validation 
point  is  associated  with  a  set  of  data  identifiers  representing  data  to  be 
collected . 

The  following  eleven  performance  attributes  are  defined  for  "alphas"  in 
an  R-Net  which  correspond  to  modules.  For  a  given  module,  not  all  of  these 
performance  attributes  may  be  applicable. 


Performance  Attribute  1:  The  ability  of  the  module  being  executed  in  paral¬ 
lel  with  another  module. 

Performance  Attribute  2:  For  each  resource  in  contention,  the  relative  time 
that  the  module  seizes  the  resource. 

Performance  Attribute  3:  For  each  resource  in  contention,  the  relative  time 
that  the  module  releases  the  resource. 

Performance  Attribute  4:  The  relative  time  that  the  module  begins  execution. 

Performance  Attribute  5:  The  relative  time  that  the  module  transmits  a 
message  to  another  module. 

Performance  Attribute  6:  The  execution  time  of  the  module. 

Performance  Attribute  7:  For  each  resource  utilized  in  the  module,  the 
resource  utilization  by  the  module.  Resource,  utilization  is  defined  as  the 
time  that  the  module  possesses  the  resource. 

Performance  Attribute  8:  For  each  data  structure,  the  storage  and  retrieval 
times  for  entries  in  the  data  structure. 

Performance  Attribute  9:  For  each  data  structure,  the  number  of  entries  in 
the  data  structure. 

Performance  Attribute  10:  For  each  data  structure,  the  service  time  of  an 
entry  in  the  data  structure,  i.e.,  the  relative  time  that  an  entry  remains 
in  the  data  structure  before  being  serviced. 

Performance  Attribute  11;  The  rate  of  input  to  the  module. 

Two  additional  performance  attributes  can  be  defined  for  "alphas"  in  an 
R-Net  which  do  not  correspond  to  modules.  These  performance  attributes  are 
needed  since  some  "alphas"  in  the  R-Net  are  critical  to  the  determination  of 
whether  or  not  certain  performance  requirements  are  affected  by  program 
modification.  These  critical  "alphas"  will  be  discussed  in  detail  in 
Section  8.1.1. 

Performance  Attribute  6';  The  execution  time  of  an  "alpha"  contained  in  a 
module . 
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Performance  Attribute  7':  The  resource  utilization  of  an  "alpha"  contained 
in  a  module  for  each  resource  utilized. 

An  additional  performance  attribute  can  also  be  defined  for  a  module. 
This  performance  attribute  is  not  related  to  the  eight  mechanisms  for  the 
propagation  of  performance  changes  as  are  the  other  thirteen  performance 
attributes.  Thus,  this  performance  attribute  is  not  affected  by  a  change  to 
a  performance  attribute  in  another  module.  It  does,  however,  correspond  to 
a  measurement  of  a  key  portion  of  the  execution  of  the  program.  The  follow¬ 
ing  is  the  additional  performance  attribute. 

Performance  Attribute  12:  For  each  dependent  iterative  structure  in  the 
module,  the  number  of  iterations.  A  dependent  iterative  structure  is  an 
iterative  structure  which  does  not  possess  a  constant  number  of  iterations, 
i.e.,  it  has  a  variable  number  of  iterations  depending  upon  certain  program 
variables . 

These  fourteen  software  performance  attributes  form  the  basis  of  per¬ 
formance  ripple  effect.  All  performance  changes  in  the  program  will  be 
analyzed  in  terms  of  these  performance  attributes.  When  a  performance  attri¬ 
bute  is  affected  by  a  modification,  the  other  performance  attributes  affected 
by  the  change  must  be  identified.  It  is  not,  however,  always  possible  to 
identify  exactly  which  performance  attributes  are  affected  as  a  consequence 
of  the  performance  ripple  effect.  When  a  particular  performance  attribute 
is  affected  by  a  modification,  it  is  possible  to  identify  the  critical  sec¬ 
tions  of  code  which  may  experience  the  performance  change.  Corresponding  to 
each  critical  section  there  may  be  several  performance  attributes.  The  con¬ 
cept  of  a  virtual  performance  attribute  is  introduced  to  represent  this 
change  in  performance  of  a  critical  section. 

A  virtual  performance  attribute  is  defined  to  represent  a  change  in 
performance  of  a  critical  section  which  is  a  consequence  of  affecting  some 
performance  attribute  in  the  program.  If  a  performance  attribute  is  involved 
in  a  performance  dependency  relationship  with  a  virtual  performance  attribute, 
it  means  that  a  change  in  the  performance  attribute  will  affect  the  virtual 
performance  attribute,  i.e.,  the  performance  of  some  software  section. 
Corresponding  to  the  virtual  performance  attribute,  there  may  be  many  per¬ 
formance  attributes. 
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The  virtual  performance  attributes  of  a  program  are  the  following: 

Virtual  Performance  Attribute  1:  The  execution  time  of  the  critical  sections 
of  a  competing  module  which  must  wait  due  to  denial  of  a  particular  contended 
resource. 

Virtual  Performance  Attribute  2:  The  execution  time  of  the  critical  sections 
of  a  module  which  contain  an  invocation  to  a  module  or  the  utilization  of  an 
abstraction. 

Virtual  Performance  Attribute  3:  The  execution  time  of  the  critical  sections 
of  a  module  which  contain  a  dependent  iterative  structure. 

Virtual  Performance  Attribute  4:  The  execution  time  of  the  critical  sections 
of  code  which  contain  a  storage  or  retrieval  request  of  an  entry  in  a  data 
structure. 

Virtual  Performance  Attribute  5:  The  execution  time  of  the  critical  sections 
of  code  which  must  wait  for  a  message  to  be  transmitted  from  another  module. 

In  Section  5.0, algorithms  will  be  presented  for  identifying  the  depen¬ 
dency  relationships  between  virtual  performance  attributes  and  performance 
attributes.  These  relationships  are  a  key  in  tracing  the  performance  ripple 
effect  among  performance  attributes.  For  example,  if  we  affect  performance 
attribute  6  of  Module  A  of  Program  X  in  Figure  4,  we  will  affect  virtual 
performance  attribute  2  of  Program  X.  Now  corresponding  to  virtual  per¬ 
formance  attribute  2  of  Program  X  is  performance  attribute  5  of  Program 
X.  Thus,  the  actual  effect  of  changing  performance  attribute  6  of  module  A 
is  a  change  in  performance  attribute  5  of  Program  X  via  virtual  performance 
attribute  2. 

3.0  FORMAL  DESCRIPTION  OF  THE  MECHANISMS  FOR  THE  PROPAGATION  OF  PERFORMANCE 
CHANGES 

In  this  section,  we  will  provide  a  formal  description  of  the  eight 
mechanisms  for  the  propagation  of  performance  changes  summarized  in  Section 
1.2.  The  relationship  of  these  mechanisms,  performance  attributes,  and 
critical  sections  will  be  shown  to  form  the  basis  for  the  concept  of  a  per¬ 
formance  change  ripple-effect  as  a  consequence  of  software  modifications. 
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Figure  4.  An  illustration  of  the  relationship 
of  virtual  performance  attributes  to 
performance  attributes  of  a  program. 


When  a  critical  section  is  modified,  it  may  affect  the  corresponding  perfor¬ 
mance  attributes.  A  change  in  these  performance  attributes  may  then  ripple, 
i.e.  affect  other  performance  attributes  via  any  applicable  mechanisms. 

These  performance  attributes  may  then,  in  turn,  affect  still  other  perfor¬ 
mance  attributes  via  the  applicable  mechanisms. 

A  performance  dependency  relationship  is  defined  to  exist  between  two 
performance  attributes  if  a  change  in  one  of  the  performance  attributes  may 
affect  the  other  performance  attribute.  If  the  performance  attributes  are 
for  different  modules,  then  a  change  in  one  of  the  performance  attributes 
may  affect  the  other  performance  attribute  only  via  one  of  the  mechanisms 
for  the  propagation  of  performance  changes. 

In  this  section,  we  will  identify  these  performance  dependency  relation¬ 
ships  among  the  performance  attributes  in  the  program  for  each  of  the  mecha¬ 
nisms  for  the  propagation  of  performance  changes.  The  performance  dependency 
relationships  among  the  performance  attributes  in  the  program  are  described 
according  to  a  set  of  rules. 

The  rules  are  of  the  format 

MODULE  X/PA.Y  -*  MODULE  Z/PA.W.  CONDITION 
and  are  interpreted  as  follows: 

A  change  in  p2rformance  attribute  Y  of  module  X  may  affect  per¬ 
formance  attribute  W  of  module  Z  if  the  condition  is  satisfied. 

A  variation  of  this  format  is  the  replaceme  it  of  MODULE  with  DS. 
which  represents  data  structures.  DS.  X/PA.Y.  is  then  interpreted 
as  the  Yth  performance  attribute  of  data  structure  X. 

In  this  section,  we  will  also  identify  the  performance  dependency  rela¬ 
tionships  in  existence  between  the  performance  attributes  and  the  virtual 
performance  attributes.  The  performance  dependency  relationships  between  the 
performance  attributes  and  virtual  performance  attributes  in  the  program  are 
described  according  to  a  set  of  rules. 

The  rules  are  of  the  format 

MODULE  X/PA.Y  -»  MODULE  Z/VPA.W.  CONDITION 
and  are  interpreted  as  follows: 
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A  change  in  performance  attribute  Y  of  module  X  may  affect  virtual 
performance  attribute  W  of  module  Z  if  the  condition  is  satisfied. 

In  this  section,  we  will  also  formally  describe  algorithms  for  identify¬ 
ing  each  of  the  mechanisms  for  the  propagation  of  performance  changes  in  the 
program.  Also  included  in  this  section  will  be  illustrative  examples  of  the 
algorithms  and  proofs  that  the  algorithms  are  correct. 

3 . 1  Parallel  Execution 

The  first  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  parallel  execution  mechanism.  This  mechanism 
analyzes  the  performance  changes  resulting  from  a  loss  of  parallel  execution 
capability.  The  major  performance  change  will  be  experienced  in  the  process 
in  which  the  module  was  executed  in  parallel.  The  primary  effect  will  be  an 
increase  in  execution  time  as  a  consequence  of  the  lost  parallelism.  The 
delay  can  be  considerable  if  the  modified  module  must  wait  for  resources 
that  were  previously  available  at  its  earlier  execution  time. 

Performance  attribute  1  is  associated  with  this  mechanism.  The  paral¬ 
lel  execution  mechanism  can  be  defined  in  terms  of  the  following  performance 
dependency  rules: 

MODULE  X/PA.l  -»  MODULE  Y/PA.4  if  X  is  involved  in  a  PIR  with 
module  Y  via  mechanism  1. 

MODULE  X/PA.l  -»  MODULE  Y/PA.6  if  X  is  in  a  PIR  with  Y  via 
mechanism  1. 

An  algorithm  has  been  developed  for  identifying  the  existence  of  the 
parallel  execution  mechanism  in  a  program  and  the  modules  in  the  program 
affected  by  this  mechanism.  This  algorithm  identifies  all  of  the  modules 
executable  in  parallel  in  the  program.  The  determination  of  which  modules 
can  be  executed  in  parallel  is  a  decision  made  during  the  design  phase  of 
the  system.  This  decision  must  be  reflected  in  either  the  software  imple¬ 
mentation  or  its  accompanying  documentation.  In  either  case,  it  can  be 
illustrated  through  the  use  of  R-Nets  [17] . 

The  identification  of  which  modules  may  be  executed  in  parallel  based 
upon  the  information  in  an  R-Net  is  easy  in  a  small  program.  For  example,  in 
the  program  illustrated  in  Figure  5,  it  is  obvious  that  modules  B  and  C, 
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Figure  5.  The  R-Net  of  a  sample  program. 
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C  and  D,  and  H  and  I  are  the  only  modules  which  may  be  executed  in  parallel. 

A  convenient  notation  for  describing  which  modules  may  be  executed  in  paral¬ 
lel  is  to  enclose  those  modules  that  may  be  executed  in  parallel  within 
parentheses.  For  example,  (A,B)  denotes  that  modules  A  and  B  may  be  executed 
in  parallel.  The  same  notation  can  be  modified  when  only  a  single  module  in 
a  set  may  be  executed  in  parallel  with  a  single  module  in  another  set.  The 
individual  modules  are  then  replaced  by  the  sets  of  which  they  belong  in  the 
notation.  For  example,  (  {A,B },  {c,D})  represents  that  either  module  A  or  B 
may  be  executed  in  parallel  with  either  module  C  or  D.  The  notation  for  the 
example  in  Figure  5  would  then  be:  {(  {B  ,D  }C)  ,  (H,I  )  }. 

The  identification  of  which  modules  may  be  executed  in  parallel  based 
upon  the  R-Net  graphs  becomes  more  difficult  as  the  complexity  and  size  of 
the  program  increases.  An  example  of  a  larger  and  more  complex  system  is 
illustrated  in  Figure  6. 

We  would  like  now  to  briefly  discuss  the  algorithm  to  identify  for  each 
module  of  a  program  the  set  of  modules  that  may  be  executed  with  it  in  paral¬ 
lel  in  the  program.  The  major  input  to  the  algorithm  consists  of  the  main 
R-Net  graph  for  the  program  and  its  subnets.  The  graphs  should  be  at  the 
level  necessary  to  define  the  parallel  execution  capability  that  may  exist 
in  the  program. 

llie  first  step  of  the  algorithm  is  the  identification  of  parallel 
control  nodes  (PONs)  for  each  graph.  A  PCN  is  defined  as  an  "AND"  node  in 
the  R-Net  with  an  out-degree  greater  than  one,  i.e.  the  PCNs  signal  the 
beginning  of  parallel  execution.  Associated  with  each  PCN  in  the  graph, 
there  is  at  least  one  "AND"  node  for  synchronizing  the  recombination  of  con¬ 
trol  flows  eminating  from  the  PCN.  The  identification  of  the  associated 
"AND"  nodes  for  each  PCN  is  accomplished  by  examining  the  points  of  inter¬ 
section  of  the  control  flows  eminating  from  the  PCN. 

The  next  task  to  be  performed  for  each  module  is  the  identification  of 
which  control  flows  pass  through  it.  All  predecessor  PCN  nodes  on  these 
control  flows  can  then  be  identified.  The  associated  "AND"  nodes  can  then 
be  identified.  Those  PCN's  with  "AND"  nodes  which  are  predecessors  of  the 
module  under  investigation  are  eliminated.  The  set  of  modules  that  can  be 
executed  in  parallel  with  the  module  under  consideration  is  then  formed  by 
adding  to  the  set  all  modules  on  control  flows  eminating  from  the  remaining 
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The  R-Net  of  a  more  complex  program 
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PCNs  and  ending  with  the  corresponding  "AND"  nodes  on  the  control  flow  of 
the  module  under  consideration.  This  set  is  supplemented  by  adding  to  it 
modules  which  are  invoked  by  modules  already  in  the  set. 

Before  we  present  the  formal  description  of  the  algorithm  for  identify¬ 
ing  the  existence  of  the  parallel  execution  mechanism  in  a  program,  we  must 
first  provide  the  definition  of  a  refined  R-Net. 

Definition:  A  refined  R-Net  is  an  R-Net  which  is  modified  in  the  following 
manner: 

(1)  Those  "AND"  nodes  in  the  graph  with  out-degree  greater  than  one  are 
relabeled  as  parallel  control  nodes  (PCNs). 

(2)  All  "AND"  nodes  and  "PCN"  nodes  are  numbered  so  that  they  are  unique. 

(3)  All  nodes  corresponding  to  alphas  are  uniquely  identified. 

(4)  Backward  branching  is  restricted  as  follows:  A  backward  branch  from  a 
decision  node  capable  of  executing  in  parallel  with  other  nodes  may  not 
be  directed  to  a  node  which  does  not  succeed  the  PCNs  responsible  for 
the  parallel  execution. 

(5)  Only  "alphas"  corresponding  to  modules  are  executable  in  parallel.  This 
restriction  simplifies  notation  and  bookkeeping  of  the  algorithms  which 
manipulate  the  R-Nets.  Parallel  execution  can  still  be  realized  at  any 
level  by  utilizing  modules. 

Figure  7  is  an  example  of  an  R-Net  which  is  not  a  refined  R-Net.  It  is 
not  refined  since  the  decision  node  following  alpha  F  is  capable  of  executing 
in  parallel  with  alpha  G,  yet  it  has  a  backward  branch  to  alpha  B  which  is  a 
predecessor  of  PCN2  which  is  responsible  for  the  parallel  execution.  It  is 
also  not  refined  since  there  are  two  nodes  labeled  C. 

Figure  8  is  an  example  of  a  refined  R-Net  since  the  decision  node 
following  alpha  C2  is  only  capable  of  executing  in  parallel  with  alpha  D,  and 
PCNl  is  responsible  for  the  parallel  execution.  Since  the  backward  branch  is 
to  node  B  and  node  B  succeeds  PCNl,  the  criterion  for  backward  branching  is 
satisfied . 

Refined  R-Nets  are  utilized  to  simplify  the  description  of  the  paths  in 
the  program.  During  the  determination  of  alphas  executable  in  parallel, 
paths  through  the  program  must  be  identified.  The  utilization  of  refined 
R-Nets  enables  backward  branches  to  be  ignored  in  path  identification  since 
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Figure  8.  The  refined  R-Net  of  a  sample  program 
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the  additional  paths  generated  by  the  backward  branches  do  not  contain  any 
new  alphas  that  can  be  executed  in  parallel  and  have  not  been  already  identi¬ 
fied  on  the  paths  without  the  backward  branches. 

It  should  be  noted  that  the  refined  R-Net  should  be  at  a  level  of 
abstraction  necessary  to  define  the  parallel  execution  in  the  program.  Each 
alpha  in  the  R-Net  corresponds  to  either  a  module  or  a  segment  of  code.  For 
each  alpha  that  corresponds  to  a  module,  there  exists  a  subnet  for  the  module. 


3.1.1  Algorithm  to  Identify  the  Parallel  Execution  Mechanism 
Algorithm  3.1.1 

Step  1:  Initialize  h»  =  0  for  each  alpha  n  which  corresponds  to  a  subnet  in 
the  graph,  h*  is  defined  to  contain  the  set  of  alphas  capable  of 
being  executed  in  parallel  with  alpha  n.  Perform  Steps  2-7  for  the 
main  program  R-Net  and  each  of  the  subnets  containing  alphas  execut¬ 
able  in  parallel. 

Step  2:  Identify  all  PCNs  in  the  R-Net  under  consideration.  Let 
P  =  {all  PCNs}. 

Step  3:  For  each  PCN  i  in  P  and  each  branch  j  from  PCN  i,  define  the  sets 

S. =  {nodes  in  the  graph  corresponding  to  alphas,  PCNs,  and  "AND" 

1 

nodes  on  a  path  from  PCN  i  through  branch  j  excluding  PCN  i}. 

For  each  PCN  i,  construct  the  sets  1\  =  {(X,Y) |x  is  of  the  form 
S^k  an<*  Y  is  the  form  S^^,^,,  where  j  ^  j '  }. 

Define  the  operator  fl*  such  that  if  A  =  (a^>a2>  •  •  •  >an)  ant^ 

B  =  {b,  ,b_ , . . .  ,b  },  then  A  (T  B  is  the  "AND"  node  in  A  with  the 
smallest  subscript  that  is  also  an  element  in  B. 

For  each  PCN  i  and  each  element  (C,Y)  in  T. ,  define  R.  =  X  D*  Y. 

R^  is  the  "AND"  node  which  synchronizes  the  paths  X  and  Y. 

Step  6:  For  each  PCN  i  and  each  element  (X,Y)  in  T\,  define  X'  =  {nodes  in 
X  corresponding  to  alphas  between  PCN  i  and  the  "AND"  node  R^Xy}- 
Also  define  Y'  =  {nodes  in  Y  corresponding  to  alphas  between  PCN  i 
and  the  "AND”  node  R^^}.  x'  an d  Y'  contain  sets  of  alphas  execut¬ 
able  in  parallel. 

Step  7;  For  each  alpha  n  in  X',  add  to  hA  all  alphas  in  Y'.  Similarly,  for 


Step  4: 

Step  5: 


For  each  alpha  n  in  X' ,  add  to  Iia  all  alphas  in  Y * , 
each  alpha  n  in  Y' ,  add  to  h«  all  alphas  in  X'. 
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Step  8: 


For  each  alpha  w  corresponding  to  a  subnet,  construct  the  set  jA  = 

{Alphas  in  subnet  w  which  correspond  to  subnets}. 

For  each  alpha  w  corresponding  to  a  subnet,  if  x  £  j*,  then  set 

=  U  j*.  Repeat  for  all  it  6  j»  until  no  new  elements  are 

added  to  i*. 

Jw 

For  each  alpha  n  corresponding  to  a  subnet,  let  the  set  h~  = 

U  1*  U  h*,  where  x,  6  h», 

*  x.  n*  in 

Xi  1 

For  each  alpha  n  corresponding  to  a  subnet,  where  n  is  an  element 

of  some  subnet,  then  let  the  set  h»  =  U  h»  U  h»,  where  n  £  I-*. 

’  n  *  w  n’  Jw 

w 

For  each  module  n  in  the  program, identify  =  {alphas  in  the  main 
R-Net  and  subnets  corresponding  to  module  n}. 

For  each  module  n,  generate  the  set  H  =  U  f(h*),  where  f(h~) 

x£M 

n 

computes  {modules  corresponding  to  the  alphas  in  h~}.  A  FIR  is 

defined  to  exist  between  module  n  and  each  of  the  modules  in  H  . 

n 

3.1.2  An  Example  for  Illustrating  Algorithm  3.1.1 

Let  us  illustrate  Algorithm  3.1.1  by  considering  the  program  described 
by  the  refined  R-Net  shown  in  Figure  9. 


Step 

J.: 

hg  = 

hc 

=  hD  =  \  =  hH  = 

II 

<M 

ht2  ~  h3  "  0 

Step 

_2 : 

For  1 

the 

Main  R-Net, 

P  = 

{PCNl  ,PCN2}. 

Step 

_3: 

Slll 

= 

{6,6,ANDl,£l,F,E2 } 

S112 

= 

{B,D,AND1,E1,PCN2, 

A  A 

(H,I) 

,AND2 ,E2 } 

S 1 2 1 

= 

{C,AND1,E1,F,E2} 

S122 

= 

{c,AND1,E1,PCN2,(H 

,1 ) ,AND2 ,E2 } 

S211 

= 

{h,AND2  ,E2  } 

S221 

= 

{i  ,AND2  ,E2  }  . 

Step 

_4: 

Let 

X1 

=  x11]L,  x2  =  sU2 

,  x3 

"  S211 

Y1 

=  s121,  y2  =  s122 

‘  Y3 

=  s22r 

Then 

T1 

=  {(X1,Y1),(X1,Y2 

),(x2 

,y1),(x2,y2)} 

t2  =  {(x3,y3)}. 


Step  9: 

Step  10: 

Step  11: 

Step  12: 

Step  13; 


* 
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**J> 


INPUT 


r 


1 


Figure  9.  The  refined  R-Net  of  a  program 

for  illustrating  Algorithm  3.1.1. 
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Figure  9.  The  refined  R-Net  of  a  program  for 

illustrating  Algorithm  3.1.1.  (cont.) 
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Step  5: 

R1X1Y1  =  AND1» 

R1X1Y2  =  ANDl, 

R1X2Y1  =  ANDl» 

R2X3Y3  =  AND2' 

R1X2Y2  =  ANDl» 

Seep  6: 

=  tB.fi} 

X3'  =  ®}. 

x2’  =  {§,6} 

Yx'  =  ©}. 

Y3'  =  tt}. 

y2’  =  {C}, 

Step  7: 

hg  =  U  Cc}, 

hg  =  h^  U  {&}, 

hg  =  bg  U  {B , D }  , 

U  ffi3 . 

hg  =  U  {X }, 

None  of  the 

other  subnets  contain  alphas 

executable  in  parallel. 

Step  8: 

%  -  *■ 

jg=  0, 

jD‘  ■  »• 

\  =  0. 

■  !5)’ 

if  =  0, 

%  *  *• 

j3=  0. 

Step  9: 

%  -  t?)  U  0. 

Step  10: 

»B  -  {cl. 

hg  =  Ib.D}, 

V  ta’- 

\  =  0’ 

hH-  -  tf), 

h^  =  {5}  U  {H} 

hf2  "  *• 

hj  =  <*• 

Step  11: 

H  -  'c"’- 

hg  =  {B ,  D  } , 

*>d  -  tel. 

\  =  0’ 

H  -  *!• 

hg  =  {H.J}, 

v  -  *- 

hJ  = 

29 


Step  12: 

M-  = 

»). 

<CJ 

II 

Mg  = 

{8}, 

Mg  =  {E1.E2}, 

Mft  = 

{H}, 

t-i? 

II 

ra 

Mj  = 

C3}. 

Step  13: 

{c}, 

Hc  =  {B,D}, 

hd  = 

{C}, 

II 

hh  = 

CO, 

HT  = 

CO. 

A  PIR  is  then  defined  to  exist  between  the  following  pairs  of  modules: 

(B,C),  (C ,D) ,  (H,I)  and  (I,J). 

3.1.3  Theorem  for  Algorithm  3.1.1 

Theorem  3.1.3:  Algorithm  3.1.1  identifies  all  sets  of  modules  that  are 
executable  in  parallel  with  a  given  module  based  on  the  R-Nets  of  the  pro¬ 
gram. 

Proof :  Let  Z  be  an  arbitrary  module  executable  in  parallel  with  modules 
,N2 , . . . ,N^.  Step  13  of  Algorithm  computes  the  set  Hz  of  modules  that  are 
executable  in  parallel  with  module  Z.  Thus,  it  must  be  shown  that  if 
Hz  =  {Y1,Y2,...,Y.},  then  J  =  K  and  faj ,N2 , . . . ,NR }  =  {Yj , Y2 , . . . .  }.  The 
proof  requires  2  parts.  In  the  first  part,  it  must  be  shown  that 
{y^,Y2> . . . >Yj]  C  {n^ ,N2 , . . . ,N^}.  The  second  part  of  the  proof  must  show  that 
{N1,N2,...,NK}  C  {Y1,Y2,...,Yj}. 

Part  1:  Establish  {y^ ,Y2 , . . . ,Y^ }  c  {n^ ,N2 , . . . ,N^}.  It  must  be  shown  that 
every  element  of  {Y^ , Y2 , . . . ,Y ^ }  is  also  an  element  of  ,N2, . . . ,NR }.  Let 
Yf  be  any  element  of  (Y^ ,Y2 , . . . ,Yj}.  We  must  consider  two  cases.  In  case  1, 
Yf  and  Z  correspond  to  alphas  on  the  same  R-Net.  In  case  2,  Yf  and  Z  corre¬ 
spond  to  alphas  on  different  R-Nets. 

Case  1:  Assume  Yr  and  Z  correspond  to  alphas  on  the  same  R-Net.  Now  Yf  6  Hz 
implies  that  there  exists  an  alpha  $  in  the  graph  corresponding  to  module 
Yr>  a  PCN  i,  and  an  element  (X,Y)  in  T^  such  that  Y^  £  Y'  and  Z  6  X'  by 
Steps  6,  7,  12,  and  13  of  the  algorithm, where  Z  is  an  alpha  in  the  graph 
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corresponding  to  module  Z.  This  implies  ?  and  2  are  on  separate  paths  from 
PCN  i  and  are  located  on  the  paths  before  by  Steps  3,45,  and  6.  Since 

is  the  "AND"  node  for  synchronizing  the  paths,  by  definition  of  the 
R-Net,  ?  and  2  are  executable  in  parallel.  Thus,  modules  Yr  and  Z  are 
executable  in  parallel  by  Steps  12  and  13. 

Case  2:  Assume  Y^_  and  Z  correspond  to  alphas  on  different  R-Nets.  Now 
Y  £  Hz  implies  that  there  exists  alphas  ^  corresponding  to  module  Yr  and 
u  such  that  €  j  and  u  f  h»  where  Z  is  an  alpha  corresponding  to  module 
Z  and  u  is  on  the  same  R-Net  as  2  by  Steps  10,  12,  and  13  of  the  algorithm. 
This  implies  there  exists  a  module  u  corresponding  to  u  on  the  same  R-Net  as 
Z  with  u  6  by  Steps  12  and  13  of  the  algorithm.  By  Case  1  of  the  proof, 
we  then  have  u  is  executable  in  parallel  with  module  Z.  Now  6  j-  implies 
by  Steps  8,  9,  12,  and  13  that  module  Yf  is  invoked  directly  or  indirectly 
by  module  u.  But  since  module  u  is  executable  in  parallel  with  module  Z  and 
Yr  is  invoked  directly  or  indirectly  by  module  u,  module  Y^  must  be  execut¬ 
able  in  parallel  with  module  Z. 

Thus,  in  either  Case  1  or  Case  2,  Y  is  executable  in  parallel  with  module  Z 
and  this  implies  Yr €  {n^,N2, . . . ,N^} .  Hence,  [Y^.y^, . . .  ,Y^.}  C  (n^,N2,  .  • .  ,N^}  . 

Part  2:  Establish  {N^ ,N2 , . . .  ,NR}  c  {y^,Y2, _ ,Yj}.  It:  must  be  shown  that 

every  element  of  {n^  ,N2 , . . .  ,Nj,}  is  also  an  element  of  {y^  ,Y2  , . . .  ,Yj}.  Let 
Nr  be  any  e'ement  of  {N1  ,N2 , . . .  ,NR] .  Now  Nr  6  ,N2 , . . .  ,NR} ,  which  implies 

that  N^  is  executable  in  parallel  with  module  Z.  We  must  consider  two  cases. 
In  Case  1,  Y^  and  Z  correspond  to  alphas  on  the  same  R-Net.  In  case  2,  Yf 
and  Z  correspond  to  alphas  on  different  R-Nets. 

Case  1 :  Assume  Nf  and  Z  correspond  to  alphas  on  the  same  R-Net.  Then  by 
definition  of  the  R-Net  structure  representing  the  program,  this  implies  that 
there  exists  a  PCN  i  with  one  branch  that  contains  an  alpha  2  corresponding 
to  module  Z  and  another  branch  that  contains  an  alpha  N  corresponding  to 

A  /\  « 

module  N^  with  both  Z  and  N^  preceding  the  "AND"  node  which  synchronizes  the 

paths.  This  implies  that  there  exists  an  element  (X,Y)  in  T,  such  that  N  €X' 

and  Z  €  Y'  by  Steps  4,  5,  and  6  of  the  algorithm.  Steo  7  theft  guarantees  that 

N  €  h.».  Steps  12  and  13  then  guarantee  N  €  H  =  {Y  ,Y» . Y  ]. 

l  z  r  z  l  z  j 
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Case  2:  Assume  and  Z  correspond  to  alphas  on  different  R-Nets.  Now  N 
is  executable  in  parallel  with  module  Z  implies  that  there  exists  a  module  u 
which  invokes  directly  or  indirectly  such  that  u  is  executable  in  parallel 
with  Z  and  u  and  Z  correspond  to  alphas  on  the  same  R-Net.  By  Case  1  of 
Part  2  of  the  proof,  this  implies  u  f  Steps  12  and  13  of  the  algorithm 

then  imply  u  6  H*, where  u  and  1  are  alphas  corresponding  to  modules  u  and  Z 
respectively.  Now  since  u  invokes  directly  or  indirectly  N^,  there  exists 
an  alpha  ]$  corresponding  to  and  such  that  N  £  by  Steps  8,  9,  12,  and 
13.  Then,  since  u  £  and  6  £  H*  by  Step  10.  Steps  12  and  13 

then  guarantee  Nr  f  Hz  =  {Y,  ,Y2, . . .  ,Yj}. 


Thus,  in  either  Case  1  or  Case  2 

{n1,n2,...,nk}  c  {y1,y2,...,yj}. 
{y1,y2,...,yj)  c  {n1,n2,...,nk}, 
{y1,y2,...,yj}. 


Nr  e  Hz  =  {yi,Y2,...,Yj},  and 
Since  {ni,N2,... ,Nk}  C  {Yj.Yg, . . . ,Yj]  and 
J  must  equal  K  and  ,N2 , . . .  jN^.}  = 


3.1.4  Identification  of  Parallel  Execution  Sets 

In  addition  to  the  identification  of  the  pairs  of  modules  executable  in 
parallel  accomplished  by  Algorithm  3.1.1,  in  large  and  complex  programs,  it 
is  also  important  to  determine  sets  consisting  of  all  modules  that  can  be 
executed  in  parallel.  These  sets  can  be  defined  as  parallel  execution  sets. 
An  example  of  a  larger  and  more  complex  system  is  illustrated  in  Figure  6. 
One  example  of  a  parallel  execution  set  from  this  example  is  {E,F,C,I,j} 
since  it  is  possible  for  each  of  the  modules  in  the  set  to  be  executed  in 
parallel.  Parallel  execution  sets  play  an  important  role  in  the  resource 
contention  problem,  since  it  is  necessary  to  determine  how  many  modules  are 
competing  for  the  fixed  number  of  available  resources.  Although  the  modules 
in  parallel  execution  sets  may  seldomly  be  executed  simultaneously  in  the 
system  due  to  their  current  relative  execution  starting  time,  the  potential 
for  their  simultaneous  execution  exists.  After  a  period  of  operation  and 
maintenance,  it  is  possible  that  the  modules  in  the  parallel  execution  sets 
could  be  executed  simultaneously  and,  therefore,  this  consideration  should 
remain  a  factor  in  determining  the  effect  of  software  modifications.  Since 
the  identification  of  the  parallel  execution  sets  is  an  important  step  in 
many  of  the  algorithms  for  identifying  the  mechanisms  for  the  propagation  of 
performance  changes,  a  common  algorithm  has  been  developed  for  accomplishing 


32 


this  objective. 

An  algorithm  to  identify  the  parallel  execution  sets  in  the  program 
will  now  be  briefly  discussed.  The  first  step  of  the  algorithm  identifies 
the  pairs  of  modules  executable  in  parallel.  This  is  accomplished  by 
invoking  Algorithm  3.1.1.  After  each  module  in  the  system  has  had  its  set 
of  modules  that  can  be  executed  in  parallel  with  it  identified,  the  parallel- 
execution  sets  can  then  be  formed.  These  sets  are  easy  to  create.  The  first 
step  is  the  selection  of  a  module  and  its  set  of  modules  that  can  be  executed 
in  parallel  with  it.  At  this  point,  there  are  at  least  two  modules  that  can 
be  executed  simultaneously.  Next,  a  module  is  selected  within  the  set  of 
parallel  executable  modules.  Its  corresponding  set  of  parallel  executable 
modules  is  then  intersected  with  the  remaining  modules  in  the  set  to  deter¬ 
mine  if  there  exists  three  modules  that  can  be  executed  simultaneously.  The 
process  is  iterated  for  all  modules  remaining  in  the  set  and  for  all  modules 
in  the  system. 

There  are  several  important  parameters  pertaining  to  software  maintain¬ 
ability  from  a  performance  perspective  that  can  be  gleaned  from  the  output  of 
this  algorithm.  For  example,  the  degree  of  parallel  influence  of  a  module 
can  be  defined  as  the  number  of  modules  which  can  be  executed  in  parallel 
with  it.  The  degree  of  parallel  influence  can  serve  as  a  measure  of  the 
complexity  of  modification  of  a  module  since  it  measures  the  number  of  poten¬ 
tial  performance  changes  in  modules  that  can  occur  as  a  result  of  a  modifica¬ 
tion. 

An  algorithm  for  identifying  the  parallel  execution  sets  in  the  program 
will  now  be  formally  described. 

3.1.5  Algorithm  to  Identify  the  Parallel  Execution  Sets  in  a  Program 
Algorithm  3.1.5 

A 

For  each  module  n,  construct  sets  h*  where  n,  are  alphas  in  the 

ni  1 

graph  corresponding  to  module  n  via  Algorithm  3.1.1. 

Select  an  alpha  n^ .  If  all  alphas  have  been  selected,  go  to  Step  9. 

If  h-»  =  0,  then  set  h'*  =  0  and  go  to  Step  2,  else  set  h'A  = 

ni  ni  ni 

{ fy. ] }  where  y,  f  h*  .  h'*  will  contain  the  set  of  parallel 

^iJ  ni  n^ 

execution  sets  for  alpha  n^. 


Step  1: 

Step  2: 
Step  3; 


i 


Step  4: 
Step  5: 

Step  6: 

Step  7: 

Step  8: 

Step  9: 

Step  10: 


3.1.6  An  Example  for  Illustrating  Algorithm  3.1.5 

Let  us  use  the  program  shown  in  Figure  10  to  illustrate  Algorithm  3.1.5. 


Step  1: 

II 

f—i 

<o 

II 

r 

he  =  {fi  ,8  ,e  ) 

hp  =  {fi.C.F} 

hg  =  fD,C,F} 

hg  =  {S,M} 

h  a  =0 

A2  V‘ 

Step  2: 

Consider  alpha  Kl. 

Step  3: 

Since  h^  =  0,  h'^  =  0. 

Step  2: 

Consider  alpha  fi. 

Step  3: 

h’g  =  tt2),fF}}. 

Step  4: 

j  =  1. 

Step  5: 

z  =  {2}. 

Step  6: 

hg  n  hg  =  0. 

Step  5: 

z  =  {*}. 

Step  6: 

hg  0  hg  =  0. 

Step  8: 

j  =  2. 

Initialize  j  =  1. 

Select  an  element,  z  =  {x. ,x., . . . ,x, ),  of  h'^.of  size  j.  If  all 

j  n, 

elements  of  size  j  have  been  selected,  go  to  Step  8. 

Compute  hA  ft  h«  ...  f|  h*  H  h*  .  If  the  intersection  is  empty,  go 

1  2  X1  nl 

to  Step  5.  3  1 

For  each  w  £  (h»  fl  h<>  . . ,  fl  h«  fl  h»  )  compute 

X1  X2  Xj  ni 

h'*  =  h '  a  u  [z  U  w}.  Go  to  Step  5. 

i  ni 

j  =  j  +  1.  If  there  are  no  new  elements  in  h'j  of  size  j,  go  to 
Step  2,  else  go  to  Step  5.  1 

For  each  module  n  in  the  program,  identify  Mn  =  {alphas  in  the  graph 
corresponding  to  module  n}. 


For  each  of  these  modules  n,  set  H'  =  U  f(h'A),  where  f(h'A) 

n  xfM  x  x 

n 

computes  the  sets  of  modules  in  Ii'a  corresponding  to  the  sets  of 
alphas  in  h'*. 
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Figure  10.  An  example  for  illustrating  Algorithm  3.1.5. 
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Figure  10.  An  example  for  illustrating  Algorithm  3.1.5  .  (cont.) 
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' . - . 


Step 

2: 

Consider  alpha  C . 

Step 

3: 

h'g  =  {{b) 

,[D},fE}}. 

Step 

4: 

j  =  1. 

Step 

5: 

z  =  {B}. 

Step 

6: 

hB  n  he = 

0. 

Step 

_5: 

z  =  {5}. 

Step 

_6: 

hi5 n  hr 

{fi}. 

Step 

_7: 

h'c  =  h'c 

U 

Step 

_5: 

z  =  {E}. 

Step 

1: 

hfi  fl  hg  = 

{6}. 

Step 

_7: 

h'c  =  h'e 

U  {{g,D}}. 

Step 

_8: 

j  =  2. 

Step 

_5 : 

z  =  {6  ,E  } . 

Step 

h6  n  hE  n 

»e-  *• 

Step 

_8: 

3=3. 

Step 

_2: 

Consider  alpha  D. 

Step 

_3 : 

h'g  =  {{£] 

!,{e},  {#}}. 

Step 

_4: 

3  =  1- 

Step 

_5 : 

z  =  [§} 

Step 

_6: 

hg  n  hg  = 

{c,F  } 

Step 

_2: 

h’6  =  h'6 

U  {{E,C},  {e,f}} 

Step 

_5: 

z  =  {«} 

Step 

_6: 

he  nhD = 

(£} 

Step 

_7: 

h ' ~  =  h'A 

U  {fc.E}} 

Step 

_5 : 

z  = 

Step 

_6 : 

hg  n  hfi  = 

m 

Step 

_7: 

h,D=h'6 

U  { [F ,  E  }  } 

Step 

_8 : 

j  =  2 

Step 

_5: 

z  =  {E,C} 

Step 

_6 : 

hfr  n  hg  n 

»«■« 

Step 

_5: 

z  =  {fi.fj 

_6 : 

hg  n  hg  n 

hD  =  0 

Step 

_8: 

j  =  3 
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Step  2; 
Step  3; 
Step  4: 
Step  5: 
Step  6: 
Step  7: 
Step  5: 
Step  6: 
Step  7: 
Step  5: 
Step  6: 
Step  7: 
Step  8: 
Step  5: 
Step  6: 
Step  5: 
Step  6: 
Step  8: 


Step  2: 
Step  3: 
Step  4: 
Step  5: 
Step  6; 
Step  5: 
Step  6: 
Step  7: 
Step  5: 
Step  6: 
Step  7: 
Step  8: 
Step  5: 
Step  6: 
Step  8: 


Consider  alpha  E 

h'g  =  UfiUC},  {*]] 
j  =  1 

*  =  m 

htf  "hg=  {C,f} 

h'g  =  hvg  u  {{fi.fi},  {d,f}] 

z  =  {fi} 

he  nhg  =  {6} 

h’g  =  h'g  U  {{C.D}} 

z  =  {?} 

hg  fl  hg  =  {6 } 

h’g  =  h'g  u  HM}} 

j  =  2 

2  =  ce,6} 
hg  n  hg  n  hg  =  0 
Z  =  (M3 
hg  n  hg  n  hg  =  0 

j  =  3 

Consider  alpha  f 

h'g  =  {{6},{6},{fi}} 
j  =  1 

*  =  {®} 

hg  n  hg  =  0 

z  =  {6} 

hfi  n  hg  =  {£} 
h'g  =  h'g  u  C05.fi}} 

z  =  {g} 

hg  nhg  =  {D} 
h'g  =  h'g  u  {{fi.fi}} 
j  =  2 

z  =  {M3 

hg  n  hg  n  hg  =  0 

1  =  3 


Step  2;  Consider  alpha  &2 
Step  3:  Since  =  0>  =  ^ 

When  the  algorithm  reaches  Step  9,  we  have: 

h'Sl  =  9 

h-g  =  {{«,{?}} 

h*e  =  {{*},»}  t*}. 

h’U  =  {»},{«}.  ffiUfi.CJJfi.fi}} 

h'j  =  {{D},  {C},  {F},  {fi.U},  ffi.F}} 
h'f  =  {{B},(D},  {El.C6.fi}} 


Step  9: 

Ma  =  {A1.A2}, 

“b  = 

{B} 

mc  =  (£}, 

”d  = 

{6} 

r— \ 

II 

Mf  = 

{*} 

Step  10: 

H\  =  0, 

h'b  =  { Cc},  {f}} 

H-c  =  {  {B  j,  (D  } ,  {e  } ,  {D  ,E  }} 
h'd  =  {fe},  {c],  {F},  {E ,  C  } ,  {E ,F } } 

H'E  =  CCD],  {c},  {f},  (c,d},{d,f}} 

H'f  =  {Cb  },  {D},  {E},{D,E}} 

3.1.7  Theorem  for  Algorithm  3.1.5 

Theorem  3.1.7:  Algorithm  3.1.5  computes  the  parallel  execution  sets  for  a 
program. 

Proof :  Let  n  be  any  module  in  the  program.  The  following  must  be  shown: 

CRITERION  1:  All  elements  of  H'  are  sets  cf  modules  executable  in  parallel 
at  the  same  time  as  module  n. 

CRITERION  2;  Every  set  of  modules  executable  in  parallel  at  the  same  time  as 
module  n  is  an  element  of  H*  . 
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Both  Criterion  1  and  Criterion  2  will  be  shown  to  be  satisfied  by  induction. 


Proof  of  Criterion  1  by  Induction:  Consider  an  arbitrary  element,  *{y},  of 
H'n  of  size  1.  Steps  3,  8,  and  9  of  Algorithm  3.1.5  guarantee  that  there 
exists  an  alpha  tu  corresponding  to  module  n  and  an  alpha  y  corresponding  to 
module  y  such  that  y  f  h*  .  By  definition  of  h«  ,  y  is  executable  in  paral¬ 
lel  with  alpha  ru.  Steps19  and  10  then  imply  module  y  is  executable  in 
parallel  with  module  n.  Thus,  CRITERION  1  is  true  for  all  elements  of  H'n 
of  size  1. 


Now  assume  all  elements  of  size  j  in  H'  satisfy  Criterion  1.  It  must 
be  shown  that  all  elements  of  size  j  +  1  also  satisfy  Criterion  1. 

Let  z  =  {x^,X2, . . . ,Xj }  be  an  arbitrary  element  of  H'n  of  size  j.  This 
implies  that  there  exists  alphas  x^,^,...,:*,  corresponding  to  modules 

»  ^  A 

XpX£ , . . .  ,Xj .  Steps  6  and  7  of  the  algorithm  select  an  alpha  w  such  that 
w  6  h*  fl  h»  ...  Rh»  Oh*  .  The  element  y  =  {xL  ,x_, . . .  ,x  ,w}  of  size 

X1  x2  Xj  n^  it  j 

j  +  1  is  then  added  to  h*  ' .  Now  since  w  (■  (h*  fl  h«  . . .  Cl  h*  0  h*  ) ,  it 

x^  x2  ni 

A  ** 

implies  w  is  executable  in  parallel  at  the  same  time  as  alphas 

x^ ,X2 , . . . ,x^ jn^.  Steps  9  and  10  then  imply  that  there  exists  a  module  w 

corresponding  to  w  which  is  executable  in  parallel  with  modules 


x^ ,X2 , . . . ,Xj ,n.  Thus,  y  satisfies  Criterion  1.  Therefore,  all  elements  of 
size  j  +  1  satisfy  Criterion  1. 

By  induction,  this  implies  all  elements  of  H'n  of  all  sizes  satisfy 
CRITERION  1 


Proof  of  Criterion  2  by  Induction:  It  must  be  shown  that  all  sets  of  modules 

executable  in  parallel  at  the  same  time  as  module  n  of  a  given  size  are 

elements  of  H'  . 

n 

Consider  sets  of  elements  of  size  1.  Let  y  be  an  arbitrary  module 
executable  in  parallel  with  module  n.  This  implies  that  there  exists  an 
alpha  y  corresponding  to  module  y  and  an  alpha  n^  corresponding  to  module  n 
such  that  yfh*.  Now  Step  3  of  the  algorithm  adds  {y}  to  h'«  .  Steps  9 
and  10  then  insure  that  {y}  is  added  to  H'n.  Thus,  all  sets  of^modules 
executable  in  parallel  at  the  same  time  as  module  n  of  size  1  are  elements  of 
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Now  assume  all  sets  of  modules  executable  in  parallel  with  module  n  of 
size  j  are  elements  of  H'n.  Let  z  =  ,x2 , . . . ,Xj »xj+1 3  be  a  set  of  modules 

executable  in  parallel  with  module  n.  This  implies  that  there  exist  alphas 

x^,x2 . x.,x.+1  corresponding  to  modules  x^ ,x2 , . . . ,x . ,x  .  . .  Let 

z  =  . . . ,Xj >x^+i }•  Now  we  have  assumed  that  there  exists  some  subset 

w  =  {x^,x2, . . . ,x. }  of  size  j  of  z  which  is  an  element  of  H'  .  This  implies 
that  there  exists  a  subset  w  =  {x^  ,x2 , . . .  ,x,  }  of  z  of  size  j  which  is  an 

A  .  A  A 

element  of  h'~  .  xj+i  ^  z  implies  xj+i  is  executable  in  parallel  with  each 

element  of  {x^  ,x2 , . . .  ,x^  }, where  n^  is  an  alpha  corresponding  to  module  n. 

This  implies  x.,,  €  (h«  fl  ...  fl  h«  Oh*').  Step  7  of  the  algorithm 

1+1  x-  x„  x.  x  r  ° 

12  j  n£ 

then  implies  z  6  H'n.  Steps  9  and  10  of  the  algorithm  then  imply  z  €  H'  . 

Therefore,  all  sets  of  modules  executable  in  parallel  at  the  same  time  as 

module  n  of  size  1+1  are  elements  of  H'  . 

J  n 

Therefore,  every  set  of  modules  executable  in  parallel  at  the  same  time 

as  module  n  are  elements  of  H'  . 

n 


3.2  Shared  Resources 

The  next  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  shared  resources  mechanism.  When  modules  are 
forced  to  share  resources,  the  time  when  each  module  requests  and  releases 
common  resources  are  important  performance  parameters.  Thus,  software  modi¬ 
fications  producing  performance  changes  in  the  time  resources  are  utilized 
can  have  detrimental  effects  on  the  performance  of  modules  that  must  also 
share  the  resources. 

Performance  attributes  2,  3,  and  4  are  associated  with  this  mechanism. 
The  shared  resources  mechanism  can  be  defined  in  terms  of  the  following 
performance  dependency  rules: 

I 

MODULE  X/PA.2  for  resource  i  -*  MODULE  Y/PA.2  for  resource  i  if 
module  X  is  involved  in  a  PIR  with  module  Y  via  mechanism  2. 


MODULE  X/PA.2  for  resource  i  -*  MODULE  Y/PA.3  for  resource  i  if 
module  X  =  module  Y  or  module  X  is  involved  in  a  PIR  with  module  Y 
via  mechanism  2. 


MODULE  X/PA.2  for  resource  i  -♦  MODULE  Y/PA.4  if  module  X  is 
involved  in  a  PIR  with  module  Y  via  mechanism  2. 
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MODULE  X/PA.2  for  resource  i  -♦  MODULE  Y/PA.7  for  resource  i  if 
module  X  =  module  Y. 

MODULE  X/PA.3  for  resource  i  -*  MODULE  Y/PA.2  for  resource  i  if 
module  X  is  involved  in  a  PIR  with  module  Y  via  mechanism  2. 

MODULE  X/PA.3  for  resource  i  -*  MODULE  Y/PA.3  for  resource  i  if 
module  X  is  involved  in  a  PIR  with  module  Y  via  mechanism  2. 

MODULE  X/PA.3  for  resource  i  -♦MODULE  Y/PA.4  if  module  X  is 
involved  in  a  PIR  with  module  Y  via  mechanism  2. 

MODULE  X/PA.3  for  resource  i  -♦MODULE  Y/PA.7  for  resource  i  if 
module  X  =  module  Y. 

MODULE  X/PA.4  -♦  MODULE  Y/PA.2  for  resource  i  if  module  X  = 

module  Y. 

V 

MODULE  X/PA.4  -♦  MODULE  Y/PA.3  for  resource  i  if  module  X  = 
module  Y. 

MODULE  X/PA.4  -♦  MODULE  Y/PA.4  if  there  exists  a  module  Z  such 
that  a  PIR  is  in  existence  between  module  Y  and  module  Z  via 

mechanism  2  and  module  X  has  precedence  over  module  Y.  Module  X 

is  defined  to  have  precedence  over  module  Y  if  module  X  is  a 
successor  of  the  PCN  controlling  the  parallel  execution  of  modules 
X  and  Z  and  a  predecessor  of  module  Y  on  a  path  from  the  PCN. 

MODULE  X/PA.6  -♦  MODULE  Y/PA.4  if  there  exists  a  module  Z  such  that 

a  PIR  is  in  existence  between  module  Y  and  module  Z  via  mechanism 
2  and  module  X  has  precedence  over  module  Y. 

MODULE  X/PA.2  for  resource  i  -♦  MODULE  Y/VPA.l  for  the  request  for 
resource  i  if  module  X  is  involved  in  a  PIR  with  module  Y  via 
mechanism  2. 

MODULE  X/PA.3  for  resource  i  -♦  MODULE  Y/VPA.l  for  the  request  for 
resource  i  if  module  X  is  involved  in  a  PIR  with  module  Y  via 
mechanism  2. 

An  algorithm  has  been  developed  for  identifying  the  existence  of  the 
shared  resources  mechanism  in  a  program  and  the  modules  in  a  program  affected 


by  this  mechanism.  To  accomplish  this  objective,  modules  sharing  a  resource 
that  can  be  executed  in  parallel  must  be  identified  by  this  algorithm.  For 
example,  if  modules  A  and  B  must  share  a  resource,  a  modification  of  resource 
utilization  in  module  A  will  not  have  an  effect  on  module  B  if  module  A  must 

complete  execution  before  module  B  can  begin.  Only  if  the  execution  of 

* 

module  A  and  module  B  overlap  can  the  modification  have  an  effect  on  perfor¬ 
mance.  The  modules  sharing  common  resources  and  executable  in  parallel  are 
then  identified  as  being  part  of  a  performance  interdependency  relationship 
since  a  modification  to  one  of  the  modules  affecting  its  resource  utilization 
can  affect  the  performance  of  the  other  modules. 

An  algorithm  for  identifying  the  shared  resources  mechanism  in  a  program 
will  now  be  formally  described. 

3.2.1  Algorithm  to  Identify  the  Shared  Resources  Mechanism 
Algorithm  3.2.1 

For  each  resource  i,  set  T^  initially  as  T^  =  {all  modules  utilizing 
resource  i }. 

For  each  module  in  T^  not  on  the  main  R-Net,  construct  =  {all 
modules  invoking  modules  in  T. }. 

Construct  T^  =  T.^  U  If  T^  ^  T^,  then  set  T^  =  T^  and  go  to 

Step  2;  otherwise  go  to  Step  4. 

Identify  sets  Hn'  of  modules  executable  in  parallel  at  the  same  time 
as  module  n  utilizing  Algorithm  3.1.5. 

For  all  modules  n  and  for  each  i  corresponding  to  a  resource  and 
each  j  corresponding  to  an  element  in  H^' ,  construct  the  set  = 

T^  H  ((jth  element  of  Hn')  U  {n}).  The  modules  in  each  set  may 

be  in  contention  for  resource  i. 

Compute  |x^.|,  i.e.  the  number  of  modules  in  for  all  i,  n  and 

j.  If  lxinjl  is  greater  than  the  number  of  resources  of  type  i, 
then  a  PIR  exists  among  the  modules  in  X^nj*  The  PIR  is  stored 
along  with  an  identification  of  the  resource  in  contention. 

3.2.2  An  Example  for  Illustrating  Algorithm  3,2.1 

To  illustrate  Algorithm  3.2.1,  let  us  consider  the  program  whose  refined 
R-Net  is  shown  in  Figure  11. 


Step  1: 

Step  2; 

Step  3: 

Step  4; 

Step  5: 

Step  6; 


43 


X2Bl  -  fe.c]. 

X2B2  *  W' 

X2C1  ’  {B'°1 

X2C2  = 

X2C3  '  (Cj ' 

X2D1  ‘  tC'Dl- 

X2E1  = 

X2pl  - 

x2F2  ■  &>). 

X2F3  "  0- 


Step  6;  jxiB1|  =  lxlB2 1  =  lxicl  I  =  lxlF1 1  =  2'  Therefore>  a  PIR  exists 

between  module  B  and  module  F  since  resource  1  exists  in  quantity  1. 
|x2Bi  ,  =  |X2d  I  =  iX2Dl  1  =  2*  Therefore,  a  PIR  exists  between 
module  B  and  module  C  and  between  module  C  and  module  D  since 
resource  2  exists  in  quantity  1. 

3.2.3  Theorem  for  Algorithm  3.2.1 

Theorem  3.2.3.  Algorithm  3.2.1  computes  sets  of  all  modules  which  may  be  in 
contention  for  a  resource. 

Proof:  Let  X^^  be  an  arbitrary  set  of  modules  which  may  be  in  contention 
for  resource  i.  The  following  must  be  shown  to  be  true: 


(1)  Any  module  in  X^^  may  be  in  contention  for  resource  i. 

(2)  Any  set  of  modules  in  contention  for  resource  i  is  contained  in  some 
set  X.  .. 

inj 

The  proof  if  the  theorem  requires  proofs  of  both  (1)  and  (2). 

Proof  of  (1);  Let  y  be  an  arbitrary  module  in  Xinj.  This  implies  that  y  €  T^ 

and  y  €  ((jth  element  of  Hn')  U  {n} ) .  Now  ,y  £  T^  implies  y  utilizes  resource 

i.  Also,  since  X^nj  is  a  set  of  modules  in  contention  for  resource  i,  |x^nj  I 

must  be  greater  than  the  number  of  resources  of  type  i.  This  implies 

|Xinj  |  a  2.  Thus,  there  exists  at  least  one  other  module,  z,  which  is  also 

an  element  of  X,  ..  Now  1  €  X.  .  and  z  €  X.  .  imply  that  y  and  z  are 

inj  J  inj  inj 
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elements  of  the  ((jth  element  of  H  ' )  U  {n}).  This  in  turn  implies  that  y 
and  z  may  be  executed  at  the  same  time. 

Therefore,  y  is  in  contention  for  resource  i  with  at  least  module  z. 


Proof  of  (2);  Let  z  =  {y^ ,y2 , . . . ,y ^ }  be  a  set  of  modules  in  contention  for 
resource  i.  This  implies  y^^,...^  are  elements  of  T ^  by  definition  of 
T^ .  Since  y^^,...^  are  executable  in  parallel,  z  -  {y^}  is  a  subset  of 
some  element  k  in  H  '  by  definition  of  H  '  .  This  implies  that  z  is  con¬ 


tained  in  the  set  X.  ,  . 

ly^ 


3.3  Interprocess  Communication 

The  next  mechanism  for  the  propagation  of  performance  changes  to'  be 
formally  described  is  the  interprocess  communication  mechanism.  When  one 
module  must  send  a  message  to  another  module,  the  performance  of  the  module 
receiving  the  message  depends  upon  when  the  message  is  actually  received. 
Thus,  modifications  to  the  module  sending  the  message  that  alter  the  time 
when  the  message  is  sent  can  affect  the  performance  of  the  module  designated 
to  receive  the  message. 

Performance  attributes  4  and  5  are  associated  with  this  mechanism. 

The  interprocess  communication  mechanism  can  be  defined  in  terms  of  the 
following  performance  dependency  rules: 


MODULE  X/PA.4  -♦  MODULE  Y/PA.4  if  there  exists  a  module  Z  such  that 
a  PDR  is  in  existence  between  module  Y  and  module  Z  via  mechanism 
3  and  module  X  has  precedence  over  module  Y. 

MODULE  X/PA.4  -♦  MODULE  Y/PA.5  for  message  i  if  module  X  =  module  Y. 

MODULE  X/PA.6  -*  MODULE  Y/PA.4  if  there  exists  a  module  Z  such  that 
a  PDR  is  in  existence  between  module  Y  and  module  Z  via  mechanism 
3  and  module  X  has  precedence  over  module  Y. 

MODULE  X/PA.5  for  message  i  -»  MODULE  Y/VPA.5  for  the  statement 
corresponding  to  a  WAIT  for  message  i. 

An  algorithm  has  been  developed  for  identifying  the  existence  of  the 
interprocess  communication  mechanism  in  a  program  and  the  modules  in  a  program 
affected  by  this  mechanism.  Interprocess  communication  can  be  identified  in 
the  software  when  synchronization  primitives  such  as  P  and  V  operators  or 
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WAIT  and  POST  macros  are  utilized.  It  is  then  possible  to  perform  a  static 
analysis  of  the  system  to  identify  the  modules  involved  in  the  communication. 
A  performance  dependency  relationship  can  then  be  established  between  the 
modules  sending  the  message  and  the  modules  receiving  the  message. 

An  algorithm  for  identifying  the  interprocess  communication  mechanism 
in  a  program  will  now  be  formally  described. 

3.3.1  Algorithm  to  Identify  the  Interprocess  Communication  Mechanism 
Algorithm  3.3.1 

Step  1:  Construct  set  P  =  {(x,y) |x  and  y  are  modules  involved  in  inter¬ 
process  communication, where  module  x  directly  transmits  a  message 
to  module  y}. 

Step  2:  For  each  pair  of  modules  i  in  P  of  the  form  (x,y),  where  x  is  not 
the  main  program,  construct  =  {modules  invoking  module  x}. 

Step  3:  For  each  module  excluding  the  main  program  in  S^,  construct 
T^  =  {all  modules  invoking  modules  in  S^}. 

Step  4:  Construct  S’  =  St  U  T^  If  S^  4  S^  then  set  St  =  S^  and  go  to 
Step  3,  otherwise  go  to  Step  5. 

Step  5:  For  each  pair  of  modules  i  in  P  of  the  form  (x,y),  set  P  = 

P  U  {(x',y)  |x'  6  S^}.  A  PDR  is  then  defined  to  exist  between  the 
first  and  second  element  of  each  ordered  pair. 


3.3.2  An  Example  for  Illustrating  Algorithm  3.3.1 

To  illustrate  Algorithm  3.3.1,  let  us  consider  the  program  whose  R-Net 
is  shown  in  Figure  12. 

Step  1;  P  =  {(Z,W)  } 

Step  2;  Sx  =  {y] 

Step  3;  Tt  =  {B } 

Step  4:  S1 '  =  {y,B} 

Since  S^  4  S,  Sx  =  {B,y} 

Step  3:  T.  =  fa, MAIN} 

Step  4:  S1'  =  {B,Y,MAIN} 

Since  S^  4  S,  Sl  =  {B,Y,MAIN} 

Step  3:  Tj  =  {B.MAIN} 


1 


MAIN 


Interprocess  Communication  for  the  Program 
1.  Module  Z  sends  a  message  to  module  W 

Figure  12.  An  example  for  illustrating  Algorithm  3.3.1. 
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Step  5;  P=  {(Z,W),(B,W),(Y,W),(MAIN,W)} 
3.3.3  Theorem  for  Algorithm  3.3.1 


Theorem  3.3.3.  Algorithm  3.3.1  identifies  those  modules  involved  in  the 
interprocess  communication  mechanism. 

Proof :  It  must  be  shown  that  the  algorithm  identifies  all  pairs  of  modules 
(x,y)  such  that  either  module  x  directly  sends  a  message  to  module  y,  or 
module  x  calls  a  module  which  in  turn  sends  a  message  to  module  Y. 

Now  Step  1  of  the  algorithm  identifies  those  pairs  of  modules  (x,y), 
where  module  x  directly  sends  a  message  to  module  y.  Steps  2,  3,  and  4  of 
the  algorithm  identify  sets  of  modules  which  call  a  module  which  in  turn 
sends  a  message  to  module  y.  Step  5  of  the  algorithm  forms  a  set  which  con¬ 
sists  of  all  pairs  of  modules  (x,y)  such  that  either  module  x  directly  sends 
a  message  to  module  y,  or  module  x  calls  a  module  which  in  turn  sends  a 
message  to  module  y. 

3 .4  Called  Modules 

The  next  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  called  modules  mechanism.  An  unbounded  modifica¬ 
tion  to  a  called  module  affects  the  performance  of  the  called  module  and, 
consequently,  affects  the  performance  of  all  modules  calling  it. 

Performance  attributes  6  and  7  are  associated  with  this  mechanism. 

The  called  modules  mechanism  can  be  defined  in  terms  of  the  following  per¬ 
formance  dependency  rules: 


MODULE  X/PA.l  -*  MODULE  Y/PA.l  if  X  is  the  dependent  module 
involved  in  a  PDR  with  module  Y  via  mechanism  4. 


MODULE  X/PA.l  -»  MODULE  Y/PA.6  if  X  is  the  dominant  module 
involved  in  a  PDR  with  module  Y  via  mechanism  4. 

MODULE  X/PA.6  -♦  MODULE  Y/PA.6  if  module  X  is  the  dominant  module 
involved  in  a  PDR  with  module  Y  via  mechanism  4. 

MODULE  X/PA.6  -♦  MODULE  Y/VPA.2  for  each  statement  invoking 


module  X  in  module  Y. 
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MODULE  X/PA.7  for  resource  i  MODULE  Y/PA.7  for  resource  i 
if  module  X  is  the  dominant  module  involved  in  a  PDR  with 
module  Y  via  mechanism  4. 

MODULE  X/PA.7  for  resource  i  -»  MODULE  Y  -  ALPHA  Z/PA.7  for 
resource  i  if  module  X  is  the  dominant  module  involved  in  a 
PDR  with  module  Y  via  mechanism  4,  and  module  X  is  called 
from  Alpha  Z. 

An  algorithm  has  been  developed  for  identifying  the  existence  of  the 
called  modules  mechanism  in  a  program  and  the  modules  in  a  program  affected 
by  this  mechanism.  It  is  very  easy  to  identify  those  modules  in  the  system 
that  are  called  by  other  modules  by  performing  a  static  analysis  of  the 
system.  Called  modules  can, then  be  identified  and  performance  dependency 
relations  established  between  the  called  modules  and  the  modules  which  call 
them. 

An  algorithm  for  identifying  the  called  modules  mechanism  in  a  program 
will  now  be  formally  described. 

3.4.1  Algorithm  to  Identify  the  Called  Modules  Mechanism 
Algorithm  3.4.1 

Step  1; 

Step  2: 

Step  3; 

Step  4: 

3.4.2  An  Example  to  Illustrate  Algorithm  3.4.1 

To  illustrate  Algorithm  3.3.2,  let  us  consider  the  program  whose  R-Net 
is  shown  in  Figure  13. 


For  each  module  i,  initialize  M^  =  {modules  directly  invoked  by 
module  i} . 

If  M^  =  0  for  all  M^ ,  terminate. 

For  each  non-empty  M^,  construct  =  {modules  directly  invoked 
by  any  module  in  M^]» 

Construct  M^ 1  =  M^  U  T,.  If  M^  =  M^'  for  each  nonempty  Mi , 

terminate;  else  set  M^  =  M^ '  and  go  to  Step  3.  A  PDR  is  then 

defined  to  exist  between  each  module  in  M.  and  module  i. 

r 


I 
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'  —  A  » 


Step  1; 


Steps  2  and  3: 


Step  4: 


^IN 

{A,B,C,D} 

MA  = 

{e.f}, 

'  “b 

=  {G}, 

MC  = 

{h}. 

”0 

=  {J,k}, 

“e  = 

0, 

”f 

=  0 

mg  = 

0, 

=  {I}, 

Ml  = 

0, 

mj 

=  Cl} 

= 

0, 

“l 

=  0. 

tmain  = 

{e,f,g,h,j,k} 

ta  = 

0, 

tb 

=  0, 

Tc  = 

{I}, 

td 

=  £l}. 

te  = 

0, 

tf 

=  0, 

tg  = 

0, 

th 

=  0, 

TI  - 

0, 

TJ 

=  0, 

T  = 

0, 

tl 

=  0. 

*WlN 

=  Mmain  =  tA’B’c’D’E’F 

.g.h.j.k} 

V 

=  {e,f} 

ma 

=  {E.F} 

V 

=  {G} 

“b 

=  Cg} 

V 

=  {H,iJ 

Mc 

=  {h.i} 

V 

=  {J.K.L} 

*D 

=  {j,k,l} 

V 

=  0 

“e 

-  0 

V 

=  0 

*F 

=  0 

V 

=  0 

mg 

=  0 

V 

=  Cl] 

“h 

=  {1} 

V 

=  0 

“l 

=  0 

V 

=  Cl} 

MJ 

=  {L} 
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Step  3: 


Step  4: 


Step  3: 


tmain 

=  {e,f,g,h,j,k,i,l} 

ta 

=  0, 

tb 

= 

Tc 

=  {I}, 

td 

= 

te 

=  0, 

tf 

= 

tg 

=  0, 

th 

= 

TI 

=  0, 

TJ 

= 

T 

K 

=  0, 

tl 

= 

Hmain 

=  =  (A>B>C>D>E>F 

,g,h,i,j,k,l} 

V 

= 

mb' 

= 

V 

=  {H,l}, 

md' 

= 

V 

=  0, 

V 

= 

V 

=  0, 

V 

= 

V 

=  0, 

V 

= 

V 

=  0, 

V 

= 

TMATM  =  (e,F,6,H,J,K,I,L} 


Step  4:  M^1N'  =  {a,B  ,C,D,E ,F,G,H,I 


MA'  =  {e,f}, 

V 

=  {g}. 

V  = 

V 

=  {j.k.l} 

Me’  =  0, 

mf' 

=  0, 

n 

V 

-  CiJ. 

V  -  0, 

V 

=  {l}. 

v  ■  *■ 

V 

=  0. 

following  PDRs  are  then  defined: 

A  ~  MAIN 

B  ~ 

MAIN 

C  ~  MAIN 

D  ~ 

MAIN 

E  ~  MAIN 

F  ~ 

MAIN 

G  -  MAIN 

H  ~ 

MAIN 

I  ~  MAIN 

J  ~ 

MAIN 

K  ~  MAIN 

L  ~ 

MAIN 

E  ~  A 
G  ~  B 
I  ~  C 
K  ~  D 
I  ~  H 


F  ~  A 
H  ~  C 
J  ~  D 
L  ~  D 
L  ~  J 


3.4.3  Theorem  for  Algorithm  3.4,1 

Theorem  3.4.3:  Algorithm  3.4.1  identifies  the  set  of  modules  that  are 
invoked  either  directly  or  indirectly  by  module  i. 

Proof :  Let  VL  =  {modules  invoked  either  directly  or  indirectly  by  module  i}. 
It  must  be  shown  that  =  IL  ,  where  is  computed  by  Algorithm  3.4.1. 

Assume  that  module  x  €  W^.  This  implies  that  module  x  is  invoked  either 
directly  or  indirectly  by  module  i.  If  x  is  invoked  directly  by  module  i, 
then  Step  1  assures  x€  M^.  If  x  is  invoked  indirectly  by  module  i,  then 
there  exists  a  sequence  of  modules  i,  x^,  X2,...,x^,  x  such  that  i  directly 
invokes  x^,  x^  directly  invokes  X2,...,  and  x^  directly  invokes  x.  Now, 

Steps  3  and  4  insure  that  x^  ,X2 , . . .  ,x^  €  M^ ,  which  implies  that  x€  M^ 
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since  x^  invokes  x.  Therefore,  c  M^. 

Now  assume  that  x6  .  This  implies  that  x  is  either  directly  invoked 

by  module  i  or  invoked  by  a  module  which  is  indirectly  invoked  by  module  i 

due  to  the  construction  of  Ik.  This  is  equivalent  to  saying  that  x€  W.^. 

Therefore,  M.  c  w.  . 

1  1 

The  combination  of  W.  c:  M.  and  M.  c  w.  implies  that  M.  =  W. . 

li  ii  ii 

3.5  Shared  Data  Structure 

The  next  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  shared  data  structures  mechanism.  The  basic 
dynamic  attributes  contributing  to  performance  in  this  area  are  a  module's 
storage  and  retrieval  times  for  entries  in  the  data  structures.  Modifica¬ 
tions  which  affect  the  quantity  of  data  stored  must  be  analyzed  to  determine 
the  effect  of  the  modification  on  the  performance  of  the  modules  utilizing 
the  shared  data  structure. 

Performance  attributes  8,  9,  and  10  are  associated  with  this  mechanism. 
The  shared  data  structures  mechanism  can  be  defined  in  terms  of  the  follow¬ 
ing  performance  dependency  rules: 

DS.X/PA.9  -*  DS.Y/PA.S  if  DS.X  =  DS.Y. 

DS.X/PA.9  -»  DS.Y/PA.10  if  DS.X  =  DS.Y. 

MODULE  X/PA.ll  -»  DS.Y/PA.9  if  module  X  stores  the  input  in  data 
structure  Y. 

DS.X/PA.8  -»  MODULE  Y/VPA.4  for  each  statement  referencing  data 
structure  X  in  module  Y. 

An  algorithm  has  been  developed  for  identifying  the  existence  of  the 
shared  data  structures  mechanism  in  a  program  and  the  modules  and  data  struc¬ 
tures  affected  by  this  mechanism. 

The  modules  manipulating  shared  data  structures  are  classified  into  four 
categories  based  upon  their  utilization  of  the  data  structure.  The  categor¬ 
ies  are: 

1.  Reference  entries  only 

2.  Update  entries 

3.  Create  new  entries 

4.  Delete  old  entries 
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It  is,  of  course,  possible  for  a  single  module  to  exist  in  more  than  one 
category. 

The  algorithm  for  identifying  performance  dependencies  in  this  area  is 
based  upon  the  general  notion  that  the  number  of  entries  in  the  data  struc¬ 
ture  affects  storage  and  retrieval  times.  One  step  of  the  algorithm  is  then 
the  classification  of  the  modules  sharing  the  data  structure  according  to  the 
above  four  categories.  Performance  dependency  relationships  are  then  estab¬ 
lished  between  the  modules  creating  and  deleting  entries  and  the  other 
modules  sharing  the  data  structure.  The  relationships  are  valid  since  a 
modification  to  the  modules  creating  or  deleting  entries  may  result  in  an 
increase  in  the  number  of  entries  in  the  data  structure.  This  may  affect 
storage  and  retrieval  times,  and  ultimately  the  performance  of  the  other 
modules  sharing  the  data  structure. 

An  algorithm  for  identifying  the  shared  data  structures  mechanism  in  a 
program  will  now  be  formally  described. 

3.5.1  Algorithm  to  Identify  the  Shared  Data  Structures  Mechanism 
Algorithm  3.5.1 

Step  1:  Construct  D  =  {shared  data  structures}. 

Step  2:  Construct  R^  =  {modules  sharing  data  structure  i}. 

Step  3;  Construct  '  =  {modules  that  create  or  delete  entires  from  data 

structure  i}.  R^'  c  R 

A  PDR  is  then  defined  to  exist  between  the  modules  in  R^ 1  and  those  in  R^ 
since  a  change  in  the  contents  of  data  structure  i  produced  by  a  module  in 
R^'  can  affect  all  the  modules  in  R^. 

3.5.2  Proof  of  Algorithm  3.5.1 

Theorem  3.5.2:  Algorithm  3.5.1  identifies  those  modules  involved  in  a  per¬ 
formance  dependency  relationship  via  the  shared  data  mechanism. 

Proof;  The  proof  of  the  theorem  requires  proofs  of  the  following  assertions: 

1.  A  performance  dependency  relationship  exists  between  each  module  in  R^' 
and  R^ . 

2.  All  performance  dependency  relationships  via  the  shared  data  mechanism 
are  between  modules  in  R^ 1  and  R^. 
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Proof  of  (1):  Let  x  be  an  arbitrary  module  such  that  x6  R^'.  Let  y  be  an 
arbitrary  module  such  that  y€  R^ .  Now,  x€  R^'  implies  by  Step  3  of  the 
algorithm  that  x  creates  or  deletes  entries  from  data  structure  i,  and  y  €  R^ 
implies  module  y  shares  data  structure  i.  Therefore,  a  performance  depen¬ 
dency  relationship  exists  between  modules  x  and  y  by  definition  of  the  shared 
data  mechanism. 

Proof  of  (2):  Assume  the  contrary,  i.e.  there  exist  modules  x  and  y  in  a 
performance  dependency  relationship  via  the  shared  data  mechanism,  but  there 
does  not  exist  an  i  such  that  x€  R^ '  and  y€  R^.  Now,  a  performance  depen¬ 
dency  relationship  between  x  and  y  via  the  shared  data  mechanism  implies  that 
there  exist  some  shared  data  structure  i  6  D.  This  implies  x  and  y  €  R^. 
Furthermore,  module  x  must  create  or  delete  entries  in  data  structure  i  for 
the  performance  dependency  relationship  to  exist.  This  implies  that  x  € R^ ' , 
which  is  impossible.  Therefore,  all  performance  dependency  relationships  via 
the  shared  data  mechanism  are  between  modules  in  R^ '  and  R^. 

3.6  Sensitivity  to  the  Rate  of  Input 

The  next  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  sensitivity  to  the  rate  of  input  mechanism. 

Changes  in  the  input  rate  to  a  process  can  have  major  repercussions  in  terms 
of  its  functional  and  performance  requirements.  For  example,  it  can  lead  to 
saturation  and  possibly  overflow  of  data  structures  involved  with  the  process¬ 
ing  of  the  input.  The  increased  frequency  of  input  arrivals  may  also  lead  to 
interruptions  in  processing  which  can  lead  to  both  functional  and  performance 
requirement  violations. 

Performance  attribute  11  is  associated  with  this  mechanism.  The 
sensitivity  to  the  rate  of  input  mechanism  cannot  be  defined  in  terms  of 
performance  dependency  rules  as  were  the  previous  mechanisms.  This  is  a 
consequence  of  the  fact  that  performance  attribute  11  is  not  affected  by 
a  change  in  performance  of  any  other  performance  attribute,  nor  does  it  have 
a  critical  section  associated  with  it.  Instead,  it  is  affected  by  a  change 
of  the  program's  operating  environment.  An  environmental  performance  depen¬ 
dency  relationship  (EPDR)  can  be  defined  in  the  following  manner.  Let  f  be 
an  attribute  of  the  program's  operating  environment  and  let  N^  be  the  set  of 
modules  which  interfaces  with  f.  An  EPDR  is  defined  between  f  and  each  of 
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the  modules  in  if  a  change  in  the  attribute  f  will  have  an  effect  on  a 
performance  attribute  for  each  of  the  modules  in  N^.  Thus,  an  EPDR  is 
defined  for  each  input  interrupt  of  type  i  and  the  modules  which  interface 
with  the  environment  to  handle  the  input  interrupts  of  type  i. 

An  algorithm  for  identifying  the  sensitivity  to  the  rate  of  input  mecha¬ 
nism  in  a  program  will  now  be  formally  described. 

3.6.1  Algorithm  to  Identify  the  Sensitivity  to  the  Rate  of  Input  Mechanism 
Algorithm  3.6.1 

Step  1;  Identify  those  sets  of  modules,  N^,  which  interface  with  the  environ¬ 
ment  to  handle  input  interrupts  of  type  i. 

Step  2:  An  EPDR  is  then  defined  to  exist  between  the  program's  operating 
environment  and  each  module  in  N. . 

l 

The  validity  of  this  algorithm  is  obvious. 

3 . 7  Execution  Priorities 

The  next  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  execution  priorities  mechanism.  It  is  important 
for  maintenance  personnel  to  recognize  the  effect  of  a  proposed  modification 
in  respect  to  the  existing  priorities  in  the  system.  For  example,  if  module  A 
has  the  ability  to  interrupt  the  execution  of  module  B,  then  any  modification 

4 

affecting  the  execution  time  of  module  B  must  be  carefully  analyzed  in  order 
to  determine  if  module  B  can  still  perform  its  designated  function  before 
being  interrupted.  Also,  modifications  to  module  A  can  affect  the  performance 
of  module  B  since  module  B  must  wait  until  the  execution  of  module  A  is  com¬ 
pleted  before  module  B  can  complete  its  execution. 

Performance  attribute  6  is  associated  with  this  mechanism.  The  execu¬ 
tion  priorities  mechanism  can  be  defined  in  terms  of  the  following  perfor¬ 
mance  dependency  rule: 

MODULE  X/PA.6  -»  MODULE  Y/PA.6  if  module  X  is  the  dominant  module 
involved  in  a  PDR  with  module  Y  via  mechanism  7. 


An  algorithm  has  been  developed  for  identifying  the  existence  of  execu¬ 
tion  priorities  mechanism  in  a  program  and  the  modules  in  a  program  affected 
by  this  mechanism.  The  execution  priorities  are  set'during  the  software 


development  phases.  These  priorities  must  be  reflected  in  either  the  soft¬ 
ware  implementation  or  in  the  accompanying  documentation.  An  algorithm  for 
identifying  the  execution  priorities  mechanism  will  now  be  formally  described. 

3.7.1  Algorithm  to  Identify  the  Execution  Priorities  Mechanism 
Algorithm  3.7.1 

For  each  module,  i,  in  the  system,  identify  the  set,  I.,  to  be  the 
set  of  modules  for  which  module  i  has  interrupt  priority;  that  is 
module  i  can  interrupt  the  execution  of  any  of  the  modules  in  1^  to 
exe cute . 

If  =  0  for  all  modules,  then  terminate. 

Construct  =  {modules  invoked  by  any  module  in  1^}  for  all  modules. 

For  each  module  i,  construct  I'.  =  I.  U  I..  If  1^  =  1'^  for  each 

module  i,  then  terminate,  else  set  1^  =  1'^  and  go  to  Step  3.  For 

each  module  i,  establish  a  PDR  between  module  i  and  each  of  the 

modules  ini.. 

l 

3.7.2  An  example  for  Illustrating  Algorithm  3.7.1 

To  illustrate  Algorithm  3.7.1,  let  us  consider  the  program  whose  R-Net 
is  shown  in  Figure  14. 

Step  1:  lA  =  {D,E} 

Step  2  and  3:  TA  =  {f,G,h} 

Step  4:  I’A  =  {D,E,F,G,H}  Ia  =  {d,E,F,G,h} 

Step  3:  Ta  =  {f,G,h} 

Step  4:  I'A  =  {D,E,F,G,H} 

The  following  PDRs  are  then  defined: 

A  ~  D  A  ~  E 

A  ~  F  A  ~  G 

A  ~  H 

3.7.3  Theorem  for  Algorithm  3.7.1 

Theorem  3.7.3:  Algorithm  3.7.1  identifies  those  modules  involved  in  a 
performance  dependency  relationship  via  the  execution  priority  sensitivity 
mechanism. 


Step  1: 


S  tep  2 
Step  3 
Step  4 
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Module  A  may  interrupt  the  execution  of  modules  D  and  E. 
Figure  14.  An  example  for  illustrating  Algorithm  3.7.1. 


Figure  14.  An  example  for  illustrating  Algorithm  3.7.1.  (cont.) 


Proof :  The  proof  of  the  theorem  requires  the  proof  of  the  following  asser¬ 
tions  : 

(1)  A  performance  dependency  relationship  exists  between  module  i  and  each 
module  in  1^  for  all  modules. 

(2)  All  performance  dependency  relationships  for  a  module  i  are  between 
module  i  and  the  modules  in  1^. 

Proof  of  (1):  Let  x  be  an  arbitrary  element  of  1^  for  some  module  i.  Step  1 
of  the  algorithm  identifies  a  set  of  modules  for  which  module  i  has  interrupt 
priority.  If  x  is  an  element  of  this  set,  then  a  PDR  exists  between  module  i 
and  module  x.  If  x  is  not  an  element  of  this  set,  then  Steps  2-4  of  the 
algorithm  guarantee  that  x  is  invoked  either  directly  or  indirectly  by  an 
element  in  this  set.  Therefore,  by  definition  of  the  execution  priority 
sensitivity  mechanism,  a  PDR  exists  between  module  i  and  module  x. 

Proof  of  (2);  Assume  the  contrary ,  i . e .  there  exists  a  module  x  such  that  a  PDR 

exists  between  module  i  and  module  x  via  the  execution  priority  sensitivity 

mechanism,  but  x $E  1^.  This  implies  module  i  can  interrupt  the  execution  of 

module  x  to  execute.  This  in  turn  implies  x  has  been  identified  to  be  inter- 

ruptable  by  module  i  or  that  x  is  invoked  either  directly  or  indirectly  by  a 

module  identified  to  be  interruptable  by  module  i.  In  the  former  case,  Step  1 

of  the  algorithm  implies  x€  I  which  is  a  contradiction.  In  the  latter  case 

Steps  2-4  of  the  algorithm  imply  x  €  1^,  which  is  again  a  contradiction. 

Therefore,  all  performance  dependency  relationships  for  a  module  i  are 

between  module  i  and  modules  in  I,  . 

l 

3 . 8  Abstractions 

The  next  mechanism  for  the  propagation  of  performance  changes  to  be 
formally  described  is  the  abstractions  mechanism.  A  change  in  the  implemen¬ 
tation  of  the  abstraction  will  very  likely  affect  the  performance  of  the 
abstraction,  and,  thus,  the  performance  of  all  modules  utilizing  the  abstrac¬ 
tion. 

Performance  attributes  6  and  7  are  associated  with  this  mechanism. 

The  abstractions  mechanism  can  be  defined  in  terms  of  the  following  perfor¬ 
mance  dependency  rules: 


66 


MODULE  X/PA.l  -»  MODULE  Y/PA.l  if  X  is  the  dependent  module 
involved  in  a  PDR  with  module  Y  via  mechanism  8. 

MODULE  X/PA.l  -*  MODULE  Y/PA.6  if  X  is  the  dominant  module  involved 
in  a  PDR  with  module  Y  via  mechanism  8. 

MODULE  X/PA.6  -*  MODULE  Y/PA.6  if  module  X  is  the  dominant  module 
involved  in  a  PDR  with  module  Y  via  mechanism  8. 

MODULE  X/PA.6  -*  MODULE  Y/VPA.2  for  each  statement  invoking  abstrac¬ 
tion  X  in  module  Y. 

MODULE  X/PA.7  for  resource  i  -»  MODULE  Y/PA.7  for  resource  i  if 
module  X  is  the  dominant  module  involved  in  a  PDR  with  module  Y 
via  mechanism  8. 

MODULE  X/PA.7  for  resource  i  -*  MODULE  Y -ALPHA  Z/PA.7'  for  resource 
i  if  module  X  is  the  dominant  module  involved  in  a  PDR  with  module 
Y  via  mechanism  8  and  invoked  by  Alpha  Z. 

An  algorithm  has  been  developed  for  identifying  the  existence  of  the 

abstraction  mechanism  in  a  program  and  the  modules  in  a  program  affected  by 

< 

this  mechanism.  The  utilization  of  abstractions  in  a  module  can  be  easily 
identified  by  static  analysis.  Abstractions  can  be  recognized  in  the  module 
as  subroutine  calls,  function  calls,  and  macros.  Performance  dependency 
relationships  can  then  be  established  between  the  implementations  of  the 
abstractions  and  the  modules  utilizing  them. 

An  algorithm  for  identifying  the  abstraction  mechanism  in  a  program  will 
now  be  formally  described. 

3.8.1  Algorithm  to  Identify  the  Abstraction  Mechfnism 
Algorithm  3.8.1 

Step  1:  For  each  module  i,  initialize  D^  =  [abstractions  directly  invoked 
by  module  i} , 

Step  2:  If  D^  =  0  for  each  module  i,  then  terminate. 

Step  3:  For  each  module  i,  construct  =  [abstractions  directly  invoked  by 
any  abstraction  in  D^}. 
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Step  4:  For  each  module  i,  construct  D'^  =  U  D^.  If  DV  =  for  each 
module  i,  then  terminate,  else  set  =  D' .  and  go  to  Step  3,  A 
FDR  is  then  defined  to  exist  between  the  implementation  of  each 
abstraction  in  and  module  i. 

3.8.2  An  Example  for  Illustrating  Algorithm  3.8.1 

To  illustrate  Algorithm  3.8.1,  let  us  consider  the  program  whose  R-Net 
is  shown  in  Figure  15 . 


Step  1: 

0A  -  (1} 

Db  -  (2,3} 

Dc  -  0 

Steps  2  &  3: 

TA  ‘  ^ 

IB  *  (4} 

Tc  -  0 

Step  4: 

D'a  =  {1,2} 

Da  -  (1,2) 

D’b  =  {2,3,4} 

»B  -  (2,3,4} 

D’c  =  0 

Dc  -  8 

Step  3: 

Ta  =  {2,4} 

Tb  =  f4,5} 

TC  =  0 

Step  4: 

D’a  =  {1,2,4} 

Da  -  (1,2,4} 

D'b  =  {2, 3, 4, 5} 

Db  -  (2,3,4,51 

D'C  =  0 

Dc  -  0 

Step  3: 

Ta  =  {2,4,5} 

Tb  =  {4,5} 

Tc  =  0 

• 
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SUBNET  A 


SUBNET  B 


SUBNET  C 


Summary  of  static  analysis  results  with  regard  to  utilization 
of  abstractions: 

MODULE  A  invokes  abstraction  1. 

MODULE  B  invokes  abstractions  2  and  3. 

ABSTRACTION  1  invokes  abstraction  2. 

ABSTRACTION  2  invokes  abstraction  4. 

ABSTRACTION  4  invokes  abstraction  5. 


Figure  15.  An  example  for  illustrating  Algorithm  3.8.1. 


Step  4: 


Step  3: 


Step  4: 


D'a  =  {1,2,4, 5} 
D'b  =  {2, 3, 4, 5} 

D'C  =  0 

Ta  =  (2,4,5} 

Tb  =  {4,5} 


TC  =  0 

D'a  =  {1,2, 4, 5} 

D'b  =  {2, 3, 4, 5} 

D’c=  0 

The  following  PDR's  are  then  defined. 

1  ~  A 

2  ~  A 

4  ~  A 

5  ~  A 


Da  =  {1,2, 4, 5} 

°B  =  t2’3’4’5} 

DC  =  0 


2  ~  B 

3  ~  B 

4  ~  B 

5  ~  B 


3.8.3  Theorem  for  Algorithm  3.8.1 

Theorem  3.8.3:  Algorithm  3.8.1  identifies  the  set  of  abstractions  that 
are  invoked  either  directly  or  indirectly  by  module  i. 

Proof :  Let  VL  =  {abstractions  invoked  directly  or  indirectly  by  module  i}. 

It  must  be  shown  that  Vk  =  D^,  where  is  computed  by  Algorithm  3.8.1. 

Assume  abstraction  x£  Vk  .  This  implies  x  is  invoked  either  directly 

or  indirectly  by  module  i.  If  x  is  invoked  directly  by  module  i,  then  Step  1 

assures  x€  D^.  If  x  is  invoked  indirectly  by  module  i,  then  there  exists  a 

sequence  of  abstractions  x^ ,X2 , . . . ,  x  such  that  i  directly  invokes  x^, 

x^  directly  invokes  X2»...,x^  directly  invokes  x.  Now  Steps  3  and  4  insure 

that  Xj ,X2 , . . . ,x^  €  implies  that  x  €  since  x^  invokes  x.  Hence, 

W.  CD,, 
l  i 

Now  assume  x€  D^.  This  implies  that  x  is  either  directly  invoked  by 
module  i  or  invoked  by  a  module  which  is  indirectly  invoked  by  module  i  due 
to  the  construction  of  D..  This  is  equivalent  to  saying  that  x  €  W. .  Hence, 


Because  W.  C  M.  and  M.  C  W.  implies  that  M.  =  W. ,  this  completes  the 
11  11  11 

proof  of  the  theorem. 

4.0  CRITICAL  SECTIONS  OF  A  PROGRAM 

Since  the  performance  attributes  of  a  program  correspond  to  measurements 
of  key  portions  of  the  execution  of  the  program,  they  can  be  affected  during 
the  maintenance  process  by  modification  to  the  program.  A  critical  section 
of  a  program  can  be  associated  with  some  performance  attributes  such  that  if 
this  critical  section  is  modified,  the  corresponding  performance  attribute 
may  be  affected.  For  example,  if  the  performance  attribute  under  considera¬ 
tion  is  the  execution  time  between  when  a  module  begins  execution  and  when 
it  transmits  a  message,  the  corresponding  critical  rection  is  that  section 
of  code  between  module  invocation  and  transmission  of  the  message.  It  should 
be  noted  that  a  critical  section  for  a  particular  performance  attribute  may 
be  part  of  another  critical  section  for  a  different  performance  attribute. 

In  this  case,  a  modification  to  a  critical  section  within  another  critical 
section  can  affect  the  corresponding  performance  attributes  of  both  critical 
sections.  The  relationship  of  performance  attributes,  critical  software 
sections,  and  the  mechanisms  for  the  propagation  of  performance  changes  is 
illustrated  in  Figure  16  where  the  directed  line  labeled  with  a  mechanism 
connecting  two  performance  attributes  indicates  that  a  performance  dependency 
relationship  exists  between  the  performance  attributes.  A  directed  line 
also  connects  each  critical  section  (CS.)  with  its  corresponding  performance 
attribute.  It  is  apparent  from  Figure  16  that  a  modification  to  CS.l  of 
Process  A  being  also  a  modification  to  CS.2  implies  that  both  PA.l  and  PA. 2 
of  Process  A  may  be  affected.  Also,  a  change  in  PA.l  of  Process  A  may  affect 
PA.l  of  Process  B  via  mechanism  1.  Thus,  the  modification  in  Process  A  can 
affect  the  performance  of  Process  B. 

The  identification  of  the  critical  sections  corresponding  to  the  per¬ 
formance  attributes  requires  algorithms  whose  input  includes  an  identifica¬ 
tion  of  the  mechanisms  in  existence  in  the  program.  In  this  section,  the 
critical  sections  in  a  program  will  be  defined.  Associated  with  each  of 
these  critical  sections  will  be  a  performance  attribute  such  that  if  this 
critical  section  is  modified,  the  corresponding  performance  attribute  may 


PROCESS  A 


PROCESS  B 


MECHANISM  1 


Figure  16.  An  example  for  illustrating  a  possible 

relationship  among  performance  attributes 
(P.A.),  critical  sections  (C.S.)  and  the 
mechanisms  for  propagation  of  performance 
changes  in  a  program. 
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be  affected.  Also  included  are  algorithms  for  identifying  all  critical 
sections  of  a  particular  type  in  the  program.  Proofs  of  the  correctness  of 
these  algorithms  are  also  included. 

4 . 1  Critical  Section  One 

Definition  4.1.  A  critical  section  of  type  one  is  defined  for  all  modules 
involved  in  a  PIR  via  mechanism  1  and  consists  of  all  of  the  blocks  in  the 
module.  This  critical  section  is  associated  with  performance  attribute  1 
such  that  if  this  critical  section  of  the  module  is  modified,  performance 
attribute  1  may  be  affected. 

The  following  algorithm  identifies  all  critical  sections  of  type 
the  program. 

Algorithm  4.1.  Identification  of  all  critical  sections  of  type 

S tep  1 .  Construct  T  =  (all  modules  involved  in  a  PIR  via  mechanism  one] . 

Step  2,  For  each  module  in  T,  designate  all  the  blocks  in  the  module  to  be 
in  the  critical  section  of  type  one  for  the  module. 

Theorem  4.1.  Algorithm  4.1  identifies  all  critical  sections  of  type  one  in 
the  program. 

Proof ;  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
critical  section  of  type  one.  Step  1  of  the  algorithm  identifies  all  the 
modules  that  have  this  critical  section  and  Step  2  identifies  all  the  blocks 
in  the  module  to  be  part  of  the  critical  section.  This  follows  exactly  with 
the  definition. 

4.2  Critical  Section  Two 

Definition  4.2.  A  critical  section  of  type  two  is  defined  for  all  modules 
involved  in  a  PIR  via  mechanism  2  and  consists  of  all  of  the  blocks  in  the 
module  between  its  invocation  and  request  for  the  resource  in  contention. 

It  may  also  consist  of  all  of  the  blocks  in  the  module  between  its  invocation 
and  its  call  to  a  module  which  utilizes  the  resource  in  contention.  A  criti¬ 
cal  section  of  type  two  is  associated  with  a  performance  attribute  of  type 
two  for  a  particular  resource  in  contention  such  that  if  this  critical  sec¬ 
tion  is  modified,  the  performance  attribute  may  be  affected. 
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The  following  algorithm  identifies  all  critical  sections  of  type  two  in 
the  program. 

Algorithm  4.2.  Identification  of  all  critical  sections  of  type  two. 

Step  1.  Select  a  set  of  modules  X  involved  in  a  PIR  via  mechanism  2.  If 
there  are  no  more  sets,  terminate. 

Step  2.  For  each  module  y  in  X,  if  y  directly  requests  the  resource  i  in 

contention  among  the  modules  in  X,  then  designate  the  blocks  in  the 
module  between  its  invocation  and  its  request  for  resource  i  to  be 
in  the  critical  section  of  type  two  for  the  module.  If  the  module 
contains  multiple  requests  for  the  resource,  it  will  have  multiple 
critical  sections. 

Step  3.  For  each  module  y  in  X,  identify  Z  =  {all  modules  invoked  directly 
or  indirectly  by  module  y} .  Construct  W  =  {modules  in  Z  which  are 
also  involved  in  a  PIR  via  mechanism  2  with  resource  i  }. 

Step  4.  For  each  module  y  in  X  and  each  module  v  in  W,  designate  the  blocks 
in  module  y  between  its  invocation  and  its  call  to  module  v  to  be 
in  a  critical  section  of  type  two  for  the  module. 

Step  5.  Go  to  Step  1. 

Theorem  4.2.  Algorithm  4.2  identifies  all  critical  sections  of  type  two  in 
the  program. 

Proof:  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
critical  section  of  type  two.  Steps  1  and  5  of  the  algorithm  identify  all 
of  the  modules  involved  in  a  PIR  via  mechanism  2.  Step  2  of  the  algorithm 
identifies  as  a  critical  section  all  of  the  blocks  in  the  module  between  its 
invocation  and  request  for  the  resource  in  contention.  This  follows  exactly 
with  the  definition.  Steps  3  and  4  of  the  algorithm  identify  as  a  critical 
section  those  blocks  in  the  module  between  its  invocation  and  its  call  to  a 
module  which  utilizes  the  resource  in  contention.  This  also  follows  exactly 
with  the  definition. 

4.3  Critical  Section  Three 

Definition  4.3.  A  critical  section  of  type  three  is  defined  for  all  modules 
involved  in  a  PIR  via  mechanism  2  which  directly  request  the  resource  in 
contention.  The  critical  section  consists  of  all  of  the  blocks  in  the 
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module  between  its  request  for  the  resource  in  contention  arid  its  release  of 
the  resource.  A  critical  section  of  type  three  is  associated  with  a  perfor¬ 
mance  attribute  of  type  three  for  a  particular  resource  in  contention  such 
that  if  this  critical  section  is  modified,  the  performance  attribute  may  be 
affected. 

The  following  algorithm  identifies  all  critical  sections  of  type  three 
in  the  program. 

Algorithm  4.3.  Identification  of  all  critical  sections  of  type  three. 

Step  1.  Select  a  set  of  modules  X  involved  in  a  PIR  via  mechanism  2.  If 
there  are  no  more  sets,  terminate. 

Step  2.  For  each  module  y  in  X,  if  y  directly  requests  the  resource  i  in 
contention  among  the  modules  in  X,  then  designate  the  blocks  in 
the  module  between  its  request  for  the  resource  in  contention  and 
its  release  of  the  resource  to  be  in  the  critical  section  of  type 
three  for  the  module. 

Step  3.  Go  to  Step  1. 

Theorem  4.3.  Algorithm  4.3  identifies  all  critical  sections  of  type  three 
in  the  program. 

Proof ;  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
critical  section  of  type  three.  Step  1  of  the  algorithm  identifies  all  of 
the  modules  involved  in  a  PIR  via  mechanism  2.  Step  2  of  the  algorithm 
identifies  as  a  critical  section  all  of  the  blocks  in  the  module  between  its 
request  for  the  resource  in  contention  and  its  release  of  the  resource.  This 
follows  exactly  with  the  definition. 

4.4  Critical  Section  Pour 

Definition  4.4.  A  critical  section  of  type  four  is  defined  for  all  dominant 
modules  involved  in  a  PDR  via  mechanism  3  aqd  consists  of  all  of  the 
blocks  in  the  module  between  its  invocation  and  its  transmission  of  the 
message.  It  may  also  consist  of  all  of  the  blocks  in  the  module  between  its 
invocation  and  its  call  to  a  module  which  in  turn  transmits  the  message.  A 
critical  section  of  type  four  is  associated  with  a  performance  attribute  of 
type  5  such  that  if  this  critical  section  is  modified,  the  performance 
attribute  may  be  affected. 
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The  following  algorithm  identifies  all  critical  sections  of  type  four 
in  the  program. 

Algorithm  4.4.  Identification  of  all  critical  sections  of  type  four. 

Step  1.  Select  a  pair  of  modules  X  involved  in  a  PDR  via  mechanism  3. 

If  there  are  no  more  pairs,  terminate. 

Step  2.  For  the  dominant  module  y  in  X,  if  y  directly  transmits  the  message 
to  the  other  module  y'  in  X,  then  designate  the  blocks  in  the  module 
between  its  invocation  and  its  transmission  of  the  message  to  be  in 
the  critical  section  of  type  four  for  the  module. 

Step  3.  For  the  dominant  module  y  in  X,  identify  Z  =  (all  modules  invoked 

directly  or  indirectly  by  y} .  Construct  W  =  {modules  in  Z  which  are 
also  in  a  PDR  with  module  y'  via  mechanism  3}. 

Step  4.  For  the  dominant  module  y  in  X  and  each  module  v  in  W,  designate 

the  blocks  in  module  y  between  its  invocation  and  its  call  to  module 
v  to  be  in  a  critical  section  of  type  four  for  the  module. 

Step  5.  Go  to  Step  1. 

Theorem  4.4.  Algorithm  4.4  identifies  all  critical  sections  of  type  four  in 
the  program. 

Proof;  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
critical  section  of  type  four.  Steps  1  and  5  of  the  algorithm  identify  all 
the  pairs  of  modules  involved  in  a  PDR  via  mechanism  3.  Step  2  of  the 
algorithm  identifies  as  a  critical  section  all  of  the  blocks  in  the  dominant 
module  in  the  pair  between  its  invocation  and  its  transmission  of  the  message. 
This  follows  exactly  with  the  definition.  Steps  3  and  4  of  the  algorithm 
identify  as  a  critical  section  those  blocks  in  the  dominant  module  in  the 
pair  between  its  invocation  and  its  call  to  a  module  which  in  turn  transmits 
the  message.  This  also  follows  exactly  with  the  definition. 

4.5  Critical  Section  Five 

Definition  4.5.  A  critical  section  of  type  five  is  defined  for  all  dominant 
modules  involved  in  a  PDR  via  mechanism  4,  7,  or  8  and  consists  of  all  the 
blocks  in  the  module.  A  critical  section  of  type  five  is  associated  with  a 
performance  attribute  of  type  six  such  that  if  this  critical  section  is 
modified,  the  performance  attribute  may  be  affected. 
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The  following  algorithm  identifies  all  critical  sections  of  type  five 
in  the  program. 

Algorithm  4.5.  Identification  of  all  critical  sections  of  type  five. 

Step  1.  Select  a  pair  of  modules  X  involved  in  a  PDR  via  mechanism  4,. 

7,  or  8.  If  there  are  no  more  pairs,  terminate. 

Step  2.  For  the  dominant  module  y  in  X,  designate  all  of  the  blocks  in  the 
module  to  be  in  the  critical  section  of  type  five  for  the  module. 
Step  3.  Go  to  Step  1. 

Theorem  4.5.  Algorithm  4.5  identifies  all  critical  sections  of  type  five 
in  the  program. 

Proof:  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
critical  section  of  type  five.  Steps  1  and  3  of  the  algorithm  identify  all 
of  the  pairs  of  modules  involved  in  a  PDR  via  mechanism  4,  7,  or  8.  Step  2 
of  the  algorithm  identifies  all  of  the  blocks  in  the  dominant  module  in 
the  pair  as  a  critical  section.  This  follows  exactly  with  the  definition. 


4 . 6  Critical  Section  Six 

Definition  4.6.  A  critical  section  of  type  six  is  defined  for  all  dominant 
modules  involved  in  a  PDR  via  mechanism  4  or  8  and  consists  of  all 
of  the  blocks  in  the  module  between  its  request  for  a  resource  and  its 
release  of  the  resource.  If  the  module  utilizes  more  than  one  resource  or 
contains  multiple  requests  for  the  same  resource,  it  will  have  multiple 
critical  sections.  A  critical  section  of  type  six  is  associated  with  a 
performance  attribute  of  type  seven  for  a  particular  resource  such  that  if 
this  critical  section  is  modified,  the  performance  attribute  may  be  affected. 

The  following  algorithm  identifies  all  critical  sections  of  type  six  in 
the  program. 

Algorithm  4.6.  Identification  of  all  critical  sections  of  type  six  in  the 
program. 

Step  1 .  Select  a  pair  of  modules  X  involved  in  a  PDR  via  mechanism  4  or  8. 
If  there  are  no  more  pairs,  terminate. 
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S tep  2 .  For  the  dominant  module  y  in  X,  if  y  directly  requests  a  resource  i, 
then  designate  the  blocks  in  the  module  between  its  request  for 
resource  i  and  its  release  of  resource  i  to  be  in  the  critical 
section  of  type  six  for  the  module. 

Step  3.  Go  to  Step  1. 

Theorem  4.6.  Algorithm  4.6  identifies  all  critical  sections  of  type  six  in 
the  program. 

Proof:  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
critical  section  of  type  six.  Steps  1  and  3  of  the  algorithm  identify  all  of 
the  pairs  of  modules  involved  in  a  PDR  via  mechanism  4  or  8.  Step  2 
of  the  algorithm  identifies  as  a  critical  section  all  of  the  blocks  in  the 
dominant  module  in  the  pair  between  its  request  for  a  particular  resource 
and  its  release  of  the  resource.  This  follows  exactly  with  the  definition. 

4. 7  Critical  Section  Seven 

Definition  4.7.  A  critical  section  of  type  seven  is  defined  for  all  modules 
containing  a  dependent  iterative  structure  and  consists  of  the  set  of  vari¬ 
ables  involved  in  the  iterative  structure,  excluding  the  index  variable. 

Each  dependent  iterative  structure  has  its  own  critical  section.  A  critical 
section  of  type  seven  is  associated  with  a  performance  attribute  of  type 
12  such  that  if  this  critical  section  is  modified,  the  performance  attri¬ 
bute  may  be  affected. 

The  following  algorithm  identifies  all  critical  sections  of  type  seven 
in  the  program. 

Algorithm  4.7.  Identification !  of  all  critical  sections  of  type  seven. 

S tep  1 .  Examine  each  module  in  the  program  and  identify  the  dependent  itera¬ 
tive  structures  in  the  module. 

Stej>_2.  For  each  dependent  iterative  structure  in  each  module,  designate  the 
set  of  variables  involved  in  the  iterative  structure,  excluding  the 
index  variable  as  a  critical  section  of  type  seven  for  the  module. 

Theorem  4.7.  Algorithm  4.7  identifies  all  critical  sections  of  type  seven 
in  the  program. 
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Proof;  The  proof  of  the  theorem  follows  trivially  from  the  definition  of  a 
critical  section  of  type  7. 

5.0  DEPENDENCY  RELATIONSHIPS  BETWEEN  VIRTUAL  PERFORMANCE  ATTRIBUTES  AND 

PERFORMANCE  ATTRIBUTES 

In  this  section,  the  performance  dependency  relationships  in  existence 
between  the  virtual  performance  attributes  and  the  performance  attributes 
presented  in  Section  2  will  be  identified.  These  performance  dependency 
relationships  are  utilized  in  the  determination  of  which  performance  attri¬ 
butes  are  affected  when  a  virtual  performance  attribute  is  affected.  For 
example,  in  Section  2  a  performance  dependency  relationship  in  existence 
between  virtual  performance  attribute  2  and  a  performance  attribute  was 
described.  In  that  example,  the  effect  of  changing  performance  attribute 
6  of  module  A  in  Figure  4  was  examined.  The  result  of  the  change  affected 
virtual  performance  attribute  2  of  program  X.  Now  since  a  performance 
dependency  relationship  exists  between  virtual  performance  attribute  2 
and  performance  attribute  5  of  program  X,  the  actual  effect  of  changing 
performance  attribute  6  of  module  A  is  a  change  in  performance  attribute 
5  of  program  X. 

In  this  section,  for  each  of  the  virtual  performance  attribute  types 
presented  in  Section  2  performance  dependency  relationship  between  the 
virtual  performance  attribute  for  a  module  and  the  performance  attributes 
for  the  module  will  be  defined.  An  algorithm  for  each  of  the  virtual  per¬ 
formance  attribute  types  will  be  presented  to  identify  the  performance  attri¬ 
butes  involved  in  the  performance  dependency  relationship  with  the  virtual 
performance  attribute  such  that  if  the  virtual  performance  attribute  is 
affected,  the  performance  attributes  are  also  affected.  Prbofs  of  the 
correctness  of  these  algorithms  will  also  be  provided. 

5 . 1  Dependency  Relationships  for  Virtual  Performance  Attribute  of  Type  One 

Definition  5.1.  A  performance  dependency  relationship  is  defined  to  exist 
between  a  virtual  performance  attribute  of  type  one  for  a  module  and  a  set 
of  performance  attributes  for  the  module  that  corresponds  to  the  critical 
sections  of  code  which  must  wait  due  to  the  denial  of  the  contended  resource 
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associated  with  the  virtual  performance  attribute  of  type  one. 

Algorithm  5.1.  Identification  of  the  dependency  relationships  in  existence 
in  a  module  between  a  virtual  performance  attribute  of  type  one  for  the 
module  and  the  performance  attributes  for  the  module. 

Step  1.  Identify  the  critical  sections  for  the  module  which  contain  the 

request  for  the  resource  in  contention  associated  with  the  virtual 
performance  attribute  of  type  one. 

Step  2.  Identify  the  performance  attributes  for  the  modules  which  are  asso- 
with  these  critical  sections. 

Step  3.  Establish  a  dependency  relationship  between  the  virtual  performance 
attribute  of  type  one  and  these  performance  attributes  such  that  if 
the  virtual  performance  attribute  is  affected,  it  will  also  affect 
these  performance  attributes. 

Theorem  5.1.  Algorithm  5.1  identifies  all  of  the  dependency  relationships 
in  existence  in  a  module  between  a  virtual  performance  attribute  of  type  one 
for  the  module  and  the  performance  attributes  for  the  module. 

Proof.  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
performance  dependency  relationship  between  a  virtual  performance  attribute 
of  type  one  for  a  module  and  the  performance  attributes  for  the  module. 

Step  1  identifies  the  critical  sections  of  the  competing  module  which  must 
wait  due  to  denial  of  a  particular  contended  resource.  Step  2  simply  identi¬ 
fies  the  performance  attributes  associated  with  these  critical  sections. 

Step  3  then  establishes  a  dependency  relationship  according  to  the  definition 
of  a  performance  dependency  relationship  between  a  virtual  performance  attri¬ 
bute  of  type  one  for  a  module  and  the  performance  attributes  for  the  module. 

5.2  Dependency  Relationships  for  Virtual  Performance  Attribute  of  Type  Two 

Definition  5.2.  A  performance  dependency  relationship  is  defined  to  exist 
between  a  virtual  performance  attribute  of  type  two  for  a  module  and  a  set 
of  performance  attributes  for  the  module  that  corresponds  to  the  critical 
sections  of  code  containing  the  invocation  to  the  module  or  abstraction 
associated  with  the  virtual  performance  attribute  of  type  two. 
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Algorithm  5.2.  Identification  of  the  dependency  relationships  in  existence 
in  a  module  between  a  virtual  performance  attribute  of  type  two  for  the 
module  and  the  performance  attributes  for  the  module. 

Step  1.  Identify  the  critical  sections  for  the  module  which  contain  the 
statement  which  invokes  the  module  or  abstraction  which  is  asso¬ 
ciated  with  the  virtual  performance  attribute  of  type  two. 

Step  2.  Identify  the  performance  attributes  for  the  modules  which  are  asso¬ 
ciated  with  these  critical  sections. 

Step  3.  Establish  a  dependency  relationship  between  the  virtual  performance 
attribute  of  type  two  and  these  performance  attributes  such  that  if 
the  virtual  performance  attribute  is  affected,  it  will  also  affect 
these  performance  attributes. 

Theorem  5.2.  Algorithm  5.2  identifies  all  of  the  dependency  relationships 
in  existence  in  a  module  between  a  virtual  performance  attribute  of  type  two 
for  the  module  and  the  performance  attributes  for  the  module. 

Proof:  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
performance  dependency  relationship  between  a  virtual  performance  attribute 
of  type  two  for  a  module  and  the  performance  attributes  for  the  module. 

Step  1  identifies  the  critical  sections  of  the  module  which  contain  an  invo¬ 
cation  to  a  module  or  the  utilization  of  an  abstraction.  Step  2  simply 
identifies  the  performance  attributes  associated  with  these  critical  sections. 
Step  3  then  establishes  a  performance  dependency  relationship  according  to 
the  definition  of  a  performance  dependency  relationship  between  a  virtual 
performance  attribute  of  type  two  for  a  module  and  the  performance  attributes 
for  the  module. 

5.3  Dependency  Relationships  for  Virtual  Performance  Attribute  of  Type  Three 

Definition  5.3.  A  performance  dependency  relationship  is  defined  to  exist 
between  a  virtual  performance  attribute  of  type  three  for  a  module  and  a  set 
of  performance  attributes  for  the  module  that  corresponds  to  the  critical 
sections  of  code  which  contain  the  storage  or  retrieval  request  of  an  entry 
from  a  data  structure  associated  with  the  virtual  performance  attribute  of 
type  three. 
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Algorithm  5.3.  Identification  of  the  dependency  relationships  in  existence 
between  a  virtual  performance  attribute  of  type  three  for  the  module  and  the 
performance  attributes  for  the  module. 

Step  1.  Identify  the  critical  sections  for  the  module  which  contain  the 

iterated  code  controlled  by  the  dependent  iterative  structure  which 
is  associated  with  the  virtual  performance  attribute  of  type  three. 
Step  2.  Identify  the  performance  attributes  for  the  module  which  are  asso¬ 
ciated  with  these  critical  sections. 

Step  3.  Establish  a  dependency  relationship  between  the  virtual  performance 
attribute  of  type  three  and  these  performance  attributes  such  that 
if  the  virtual  performance  attribute  is  affected,  it  will  also 
affect  these  performance  attributes. 

Theorem  5.3.  Algorithm  5.3  identifies  all  of  the  dependency  relationships 
in  existence  in  a  module  between  a  virtual  performance  attribute  of  type 
three  for  the  module  and  the  performance  attributes  for  the  module. 

Proof :  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
performance  dependency  relationship  between  a  virtual  performance  attribute 
of  type  three  for  a  module  and  the  performance  attributes  for  the  module. 

Step  1  identifies  the  critical  sections  of  the  module  which  contain  the 
iterated  code  controlled  by  the  dependent  iterative  structure.  Step  2  simply 
identifies  the  performance  attributes  associated  with  these  critical  sections. 
Step  3  then  establishes  a  performance  dependency  relationship  according  to 
the  definition  of  a  performance  dependency  relationship  between  a  virtual 
performance  attribute  of  type  three  for  a  module  and  the  performance  attri¬ 
butes  for  the  module. 


5.4  Dependency  relationships  for  Virtual  Performance  Attribute  of  Type  Four 

Definition  5.4.  A  performance  dependency  relationship  is  defined  to  exist 
between  a  virtual  performance  attribute  of  type  four  for  a  module  and  a  set 
of  performance  attributes  for  the  module  that  corresponds  to  the  critical 
sections  of  code  which  contain  the  storage  or  retrieval  request  of  an  entry 
from  a  data  structure  associated  with  the  virtual  performance  attribute  of 
type  four. 
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Algorithm  5.4.  Identification  of  the  dependency  relationships  in  existence 
in  a  module  between  a  virtual  performance  attribute  of  type  four  for  the 
module  and  the  performance  attributes  for  the  module. 

Step  1.  Identify  the  critical  sections  for  the  module  which  contain  the 

reference  to  the  data  structure  which  is  associated  with  the  virtual 
performance  attribute  of  type  four. 

Step  2.  Identify  the  performance  attributes  for  the  module  which  are  asso¬ 
ciated  with  these  critical  sections. 

Step  3.  Establish  a  dependency  relationship  between  the  virtual  performance 
attribute  of  type  four  and  these  performance  attributes  such  that 
if  the  virtual  performance  attribute  is  affected,  it  will  also 
affect  these  performance  attributes. 

Theorem  5.4.  Algorithm  5.4  identifies  all  of  the  dependency  relationships 
in  existence  in  a  module  between  a  virtual  performance  attribute  of  type 
four  for  the  module  and  the  performance  attributes  for  the  module. 

Proof;  The  proof  the  theorem  follows  directly  from  the  definition  of  a  per¬ 
formance  dependency  relationship  between  a  virtual  performance  attribute  of 
type  four  for  a  module  and  the  performance  attributes  for  the  module.  Step  1 
identifies  the  critical  sections  of  code  containing  references  to  data  struc¬ 
tures.  Step  2  simply  identifies  the  performance  attributes  associated  with 
these  critical  sections.  Step  3  then  establishes  a  performance  dependency 
relationship  according  to  the  definition  of  a  performance  dependency  rela¬ 
tionship  between  a  virtual  performance  attribute  of  type  four  for  a  module 
and  the  performance  attributes  for  the  module. 

5 . 5  Dependency  Relationships  for  Virtual  Performance  Attribute  of  Type  Five 

Definition  5.5.  A  performance  dependency  relationship  is  defined  to  exist 
between  a  virtual  performance  attribute  of  type  five  for  a  module  and  a  set 
of  performance  attributes  for  the  module  that  corresponds  to  the  critical 
sections  of  code  which  must  wait  for  the  message  to  be  transmitted  from 
another  module  which  is  associated  with  the  virtual  performance  attribute 
of  type  five. 
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Algorithm  5.5.  Identification  of  the  dependency  relationships  in  existence 
in  a  module  between  a  virtual  performance  attribute  of  type  five  for  the 
module  and  the  performance  attributes  for  the  module'^ 

Step  1.  Identify  the  critical  sections  for  the  module  which  contain  the 

WAIT  statement  for  the  message  associated  with  the  virtual  perfor¬ 
mance  attribute  of  type  five. 

Step  2.  Identify  the  performance  attributes  for  the  module  which  are  asso¬ 
ciated  with  these  critical  sections. 

Step  3.  Establish  a  dependency  relationship  between  the  virtual  performance 
attribute  of  type  five  and  these  performance  attributes  such  that 
if  the  virtual  performance  attribute  is  affected,  it  will  also 
affect  these  performance  attributes. 

Theorem  5.5.  Algorithm  5.5  identifies  all  of  the  dependency  relationships  in 
existence  in  a  module  between  a  virtual  performance  attribute  of  type  five 
and  the  performance  attributes  for  the  module. 

Proof;  The  proof  of  the  theorem  follows  directly  from  the  definition  of  a 
performance  dependency  relationship  between  a  virtual  performance  attribute 
of  type  five  for  a  module  and  the  performance  attributes  for  the  module. 

Step  1  identifies  the  critical  sections  of  code  which  must  wait  for  a  message 
to  be  transmitted  from  another  module.  Step  2  simply  identifies  the  perfor¬ 
mance  attributes  associated  with  these  critical  sections.  Step  3  then  estab¬ 
lishes  a  performance  dependency  relationship  according  to  the  definition  of  a 
performance  dependency  relationship  between  a  virtual  performance  attribute 
of  type  five  for  a  module  and  the  performance  attributes  for  the  module. 

6.0  PERFORMANCE  DEPENDENCY  RELATIONSHIP  RULES 

In  this  section,  all  of  the  performance  dependency  relationship  rules 
utilized  in  the  formal  description  of  the  mechanisms  for  the  propagation  of 
performance  changes  in  Section  3  will  be  compiled.  This  list  of  performance 
dependency  relationship  rules  will  be  completed  with  rules  which  were  not 
utilized  in  the  description  of  the  mechanisms. 

The  performance  dependency  relationships  among  the  performance  attri¬ 
butes  in  the  program  are  described  according  to  the  following  set  of  rules. 
The  rules  are  of  the  format: 
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MODULE  X/PA.Y  -»  MODULE  Z/PA.W  CONDITION 
and  are  interpreted  as  follows: 

A  change  in  performance  attribute  Y  of  module  X  may  affect  performance 
attribute  W  of  module  Z  if  the  condition  is  satisfied.  A  variation  of  this 
format  is  the  replacement  of  MODULE  with  DS .  which  represents  data  structure. 
DS.  X/PA.Y  is  then  interpreted  as  the  Yth  performance  attribute  of  data 
structure  X. 

The  rules  for  describing  performance  dependency  relationships  among  the 
performance  attributes  in  the  program  are  the  following: 

MODULE  X/PA.l  ■+  MODULE  Y/PA.l  if  X  is  the  dependent  module 
involved  in  a  PDR  with  module  Y  via  mechanism  1,  4,  or  8. 

MODULE  X/PA.l  -»  MODULE  Y/PA.4  if  X  is  involved  in  a  PDR  with 
module  Y  via  mechanism  1. 

MODULE  X/PA.l  -*  MODULE  Y/PA.6  if  X  is  the  dominant  module  involved 
in  a  PDR  with  module  Y  via  mechanism  4,  8,  or  1. 

MODULE  X/PA.2  for  resource  i  -*  MODULE  Y/PA.2  for  resource  i  if 
module  X  is  involved  in  a  PIR  with  module  Y  via  mechanism  2.. 

MODULE  X/PA.2  for  resource  i  -*  MODULE  Y/PA.3  for  resource  i  if 
module  X  =  module  Y  or  module  X  is  involved  in  a  PIR  with  module 
Y  via  mechanism  2. 

MODULE  X/PA.2  for  resource  i  -»  MODULE  Y/PA.4  if  module  X  is 
involved  in  a  PIR  with  module  Y  via  mechanism  2. 

MODULE  X/PA.2  for  resource  i  -»  MODULE  Y/PA.7  for  resource  i  if 
module  X  =  module  Y. 

MODULE  X/PA.3  for  resource  i  -*  MODULE  Y/PA.2  for  resource  i  if 
module  X  is  involved  in  a  PIR  with  module  Y  via  mechanism  2. 

MODULE  X/PA.3  for  resource  i  -*  MODULE  Y/PA.3  for  resource  i  if 
module  X  is  involved  in  a  PIR  with  module  Y  via  mechanism  2. 

MODULE  X/PA.3  for  resource  i  -♦  MODULE  Y/PA.4  if  module  X  is 
involved  in  a  PIR  with  module  Y  via  mechanism  2. 
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MODULE  X/PA.3  for  resource  i  -»  MODULE  Y/PA.7  for  resource  i  if 
module  X  =  module  Y. 


MODULE  X/PA.4  -♦  MODULE  Y/PA.2  for  resource  i  if  module  X  = 
module  Y. 

MODULE  X/PA.4  -*  MODULE  Y/PA.3  for  resource  i  if  module  X  = 
module  Y. 

MODULE  X/PA.4  -*  MODULE  Y/PA.4  if  there  exists  a  module  Z  such 
that  a  PDR  is  in  existence  between  module  Y  and  module  Z  via 
mechanism  2  or  3  and  module  X  has  precedence  over  module  Y. 

MODULE  X/PA.4  -»  MODULE  Y/PA.5  for  message  i  if  module  X  =  module  Y. 

MODULE  X/PA.6  -*  MODULE  Y/PA.4  if  there  exists  a  module  Z  such 
that  a  PDR  is  in  existence  between  module  Y  and  module  Z  via 
mechanism  2  or  3  and  module  X  has  precedence  over  module  Y. 

MODULE  X/PA.6  -»  MODULE  Y/PA.6  if  module  X  is  the  dominant  module 
involved  in  a  PDR  with  module  Y  via  mechanism  4,  7,  or  8. 

MODULE  X/PA.7  for  resource  i  -»  MODULE  Y/PA.7  for  resource  i  if 
module  X  is  the  dominant  module  involved  in  a  PDR  with  module  Y 
via  mechanism  4  or  8. 

MODULE  X/PA.7  for  resource  i  -♦  MODULE  Y-ALPHA  Z/PA.7'  for  resource 
i  if  module  X  is  the  dominant  module  involved  in  a  PDR  with  module 
Y  via  mechanism  4  and  the  call  to  module  X  is  in  Alpha  z. 

DS.X/PA.9  -►  DS.Y/PA.8  if  DS.X  =  DS.Y 

DS.X/PA.9  DS.Y/PA.10  if  DS.X  =  DS.Y 

MODULE  X/PA.ll  -»  DS.Y/PA.9  if  module  X  stores  the  input  in  data 
structure  Y. 

The  performance  dependency  relationships  in  existence  between  the  per¬ 
formance  attributes  and  the  virtual  performance  attributes  in  the  program 
are  described  according  to  the  following  set  of  rules.  The  rules  are  of  the 
format : 
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MODULE  X/PA.Y  -*  MODULE  Z/VPA.W  CONDITION 


and  are  interpreted  as  follows: 

A  change  in  performance  attribute  Y  of  module  X  may  affect  virtual  per¬ 
formance  attribute  W  of  module  Z  if  the  condition  is  satisfied.  The  rules 
for  describing  performance  dependency  relationships  between  the  performance 
attributes  and  the  virtual  performance  attributes  in  the  program  are  the 
following: 

MODULE  X/PA.2  for  resource  i  -*  MODULE  Y/VPA.l  for  the  request  for 
resource  i  if  module  X  is  involved  in  a  PIR  with  module  Y  via 
mechanism  2. 

MODULE  X/PA.3  for  resource  i  -»  MODULE  Y/VPA.l  for  the  request  for 
resource  i  if  module  X  is  involved  in  a  PIR  with  module  Y  via 
mechanism  2. 

MODULE  X/PA.6  -*  MODULE  Y/VPA.2  for  each  statement  invoking  module 
X  in  module  Y. 

DS.X/PA.8  -*  MODULE  Y/VPA.4  for  each  statement  referencing  data 
structure  X  in  module  Y. 

MODULE  X/PA.5  for  message  i  -»  MODULE  Y/VPA.5  for  the  statement 
corresponding  to  a  WAIT  for  message  i. 

One  additional  performance  dependency  relationship  can  be  defined 
between  a  performance  attribute  and  a  virtual  performance  attribute  that  was 
not  defined  in  Section  3.  The  performance  dependency  relationship  is 
described  according  to  the  following  rule: 

MODULE  X/PA.12  for  dependent  iterative  structure  i  ■+  MODULE 
Y/VPA.3  for  dependent  iterative  structure  i  if  module  X  =  module  Y. 

This  performance  dependency  relationship  rule  was  not  defined  in 
Section  3  since  there  are  not  any  mechanisms  for  the  propagation  of  perfor¬ 
mance  changes  defined  in  terms  of  this  performance  dependency  relationship. 
This  is  a  consequence  of  the  fact  that  performance  attribute  12  is  not 
related  to  the  eight  mechanisms  for  the  propagation  of  performance  changes 
as  discussed  in  Section  2. 
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7.0  RIPPLE  EFFECT  OF  PERFORMANCE  CHANGES 

The  maintainability  of  a  software  system  is  a  measure  of  the  ease  cf 
performing  maintenance  to  the  software  system,  and  ■all  maintenance  activities 
require  modifications  to  the  system.  The  effect  of  a  modification  to  a  soft¬ 
ware  system  may  not  be  local  to  the  location  of  the  modification,,  but  may  also 
affect  other  portions  of  the  system.  This  means  a  ripple  effect  existing  from 
the  location  of  the  modification  to  the  other  parts  of  the  system  that  are 
affected  by  the  modification.  One  aspect  of  this  ripple  effect  is  logical  or 
functional  in  nature,  and  another  concerns  the  performance  of  the  system. 

The  concept  of  a  performance  change  ripple  effect  as  a  consequence  of 
software  modification  is  analyzable  by  examination  of  the  relationship  of 
performance  attributes,  virtual  performance  attributes,  critical  sections 
and  the  mechanisms  for  the  propagation  of  performance  changes.  Performance 
dependency  relationships  among  performance  attributes  and  between  perfor¬ 
mance  attributes  *nd  virtual  performance  attributes  were  described  in  terms 
of  the  performance  dependency  rules  presented  in  Section  6.  The  performance 
dependency  relationships  between  virtual  performance  attributes  and  perfor¬ 
mance  attributes  were  described  in  Section  5.  With  these  performance  depen¬ 
dency  relationships  it  is  possible  to  determine  the  ripple  effect  of  perfor¬ 
mance  changes  as  a  consequence  of  program  modification. 

This  ripple  effect  of  performance  changes  is  computed  by  first  identify¬ 
ing  the  corresponding  performance  attributes  affected  by  modification  of  a 
critical  section.  A  change  in  these  performance  attributes  may  then  ripple, 
i.e.,  affect  other  performance  attributes  or  virtual  performance  attributes 
according  to  the  applicable  performance  dependency  relationship  rules.  If  a 
virtual  performance  attribute  is  affected,  the  corresponding  performance 
attributes  which  are  affected  can  be  identified  by  the  algorithms  in  Section 
5.  These  affected  performance  attributes  may  then  affect  still  other  perfor¬ 
mance  attributes  and  virtual  performance  attributes  which  accounts  for  the 
ripple  effect  of  performance  changes. 

For  example,  consider  the  three  modules  of  a  program  presented  in 
Figure  17.  If  a  modification  to  module  X  occurs  affecting  performance  attri¬ 
bute  6,  there  is  a  ripple  effect  of  performance  changes  affecting  all  three 
modules.  The  change  in  performance  attribute  6  will  affect  virtual  perfor¬ 
mance  attribute  2  of  module  Y  according  to  the  performance  dependency  rule 
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MODULE  X 


MODULE  Y 


START 


Figure 


START 


CALL  MODULE  X 


SEND  MESSAGE  TO  MODULE  Z 


STOP 


MODULE  Z 
START 


WAIT  FOR  MESSAGE 
FROM  MODULE  Y 


STOP  - 


17.  An  example  to  illustrate  the  ripple 
effect  of  performance  changes. 


between  performance  attribute  6  and  virtual  performance  attribute  two  in 
Section  6.  Now  a  change  in  virtual  performance  attribute  two  will  affect 
performance  attributes  5  and  6  of  module  Y  according  to  Algorithm  5.2, 
and  a  change  in  performance  attribute  5  of  module  Y  will  affect  virtual 
performance  attribute  five  of  module  Z  according  to  the  performance  depen¬ 
dency  rule  between  performance  attribute  5  and  virtual  performance  attri¬ 
bute  five  in  Section  6.  This  change  in  virtual  performance  attribute  five 
of  module  Z  will  affect  performance  attribute  6  of  module  Z  according  to 
Algorithm  5.5.  Thus,  there  exists  a  performance  ripple  effect  among  the 
three  modules. 


8.0  MAINTENANCE  TECHNIQUE  FOR  PREDICTING  WHICH  PERFORMANCE  REQUIREMENTS  ARE 

AFFECTED  BY  THE  MAINTENANCE  ACTIVITY 

The  maintenance  process  can  be  improved  if  maintenance  personnel  are 
supplied  with  information  enabling  them  to  incorporate  performance  considera¬ 
tions  in  their  criteria  for  selecting  the  type  and  location  of  program  modi¬ 
fications  to  be  made.  This  information  is  provided  by  the  development  of  a 
maintenance  technique  for  predicting  which  performance  requirements  in  the 
program  may  be  affected  by  a  proposed  modification.  The  prediction  of  which 
performance  requirements  may  be  affected  by  a  program  modification  is  a 
difficult  task  due  to  the  size  and  complexity  of  design  of  many  large-scale 
software  systems.  Thus,  the  significance  of  this  maintenance  technique  lies 
in  its  ability  to  trace  repercussions  introduced  by  maintenance  changes  and 
predict  which  performance  requirements  may  be  affected  by  the  change.  The 
technique  developed  here  is  applicable  to  all  types  of  large-scale  software 
systems  possessing  performance  requirements  including  multiprocessing  systems. 

In  this  section,  a  maintenance  technique  for  predicting  which  perfor¬ 
mance  requirements  are  affected  by  a  proposed  program  modification  will  be 
formally  described.  Section  8.1  contains  some  key  algorithms  and  guidelines 
composing  this  maintenance  technique.  Section  8.2  contains  the  complete 
description  of  the  maintenance  technique.  Section  8.3  contains  a  proof  of 
the  correctness  of  the  algorithms  composing  the  maintenance  technique. 

Finally,  Section  8.4  provides  an  application  of  the  maintenance  technique  to 
the  retesting  phase  of  the  maintenance  process. 
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8.1  Key  Algorithms  and  Guidelines  Composing  the  Maintenance  Technique 

In  ^.this  section  some  of  the  key  algorithms  composing  the  maintenance 

technique  will  be  formally  described.  Proofs  of  the  correctness  of  these 
algorithms  will  also  be  provided.  Some  guidelines  for  the  decomposition  of 
performance  requirements  into  performance  attributes  will  also  be  discussed. 

8.1.1  Guidelines  for  the  Decomposition  of  Performance  Requirements  into 
Performance  Attributes 

An  important  step  of  the  maintenance  technique  to  be  described  in 
Section  8.2  is  the  decomposition  of  the  program's  performance  requirements 
into  the  performance  attributes  for  the  program.  In  our  previous  report  a 
few  approaches  to  the  statement  of  performance  requirements  were  reviewed 
[17],  The  current  approach  in  software  engineering  to  the  statement  of 
performance  requirements  in  terms  of  flows  through  the  system  was  also 
described.  This  approach  utilizes  R-Nets,  which  are  also  defined  in  our 
earlier  report  [17]. 

In  this  section,  the  decomposition  of  performance  requirements  into 
performance  attributes  will  be  investigated.  The  decomposition  of  a  perfor¬ 
mance  requirement  quantitatively  into  the  effect  of  its  corresponding  perfor¬ 
mance  attributes  is  a  very  complex  task  which  is  not  attempted  in  this  tech¬ 
nique.  Instead,  the  decomposition  is  qualitative  in  nature,  i.e.,  performance 
attributes  which  contribute  to  the  preservation  or  violation  of  performance 
requirements  without  consideration  of  their  relative  magnitude  towards  the 
performance  requirements  are  identified.  This  simplification  is  justified 
because  this  maintenance  technique  attempts  to  identify  performance  require¬ 
ments  which  may  be  violated  due  to  the  maintenance  effort,  and  does  not 
attempt  to  analytically  confirm  whether  or  not  a  performance  requirement  is 
actually  violated. 

Since  the  current  trend  in  stating  performance  requirements  is  at  the 
R-Net  level,  in  this  section  the  emphasis  will  be  on  the  decomposition  of 
performance  requirements  stated  at  the  R-Net  level  into  performance  attri¬ 
butes.  Two  general  categories  of  performance  requirements  will  be  investi¬ 
gated.  The  first  category  concerns  the  performance'  requirement  that  a 
certain  task  be  performed  in  a  specified  execution  time.  The  second  category 
concerns  the  performance  requirement  that  this  task  be  performed  with  resource 
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utilization  restrictions.  Now  these  performance  requirements  are  testable 
if  they  are  stated  in  terms  of  the  validation  points  identified  on  the  R-Net. 
The  guidelines  for  the  decomposition  of  performance  requirements  into  per¬ 
formance  attributes  are  based  upon  the  assumption  that  these  performance 
requirements  are  stated  in  terms  of  validation  points  on  the  R-Nets.  Further¬ 
more,  it  is  assumed  that  the  R-Nets  are  refined  until  each  "Alpha"  in  the 
graph  corresponds  to  a  module  or  a  segment  of  code  in  a  module. 

The  decomposition  of  the  performance  requirements  into  the  performance 
attributes  can  then  be  accomplished  in  the  following  way: 

Step  1.  Analyze  each  performance  requirement.  If  the  performance  require¬ 
ment  states  that  the  program  executes  in  a  specified  time  between 
two  validation  points,  then  identify  the  modules  or  segments  of 
code  corresponding  to  the  "Alphas"  on  the  R-Net  between  the  valida¬ 
tion  points.  For  each  of  these  modules,  designate  PA. 6  to  be  a 
performance  attribute  for  the  module. 

For  each  of  the  segments  of  code  identified,  designate  PA. 6'  to  be 
a  performance  attribute  for  the  segment.  Also,  designate  critical 
section  5'  to  contain  all  of  the  blocks  in  the  segment  of  code 
corresponding  to  the  "Alpha"  on  the  R-Net.  PA. 6'  is  associated 
with  CS.5'  such  that  if  CS.5'  is  modified,  then  PA. 6'  may  be 
affected. 

Decompose  the  performance  requirement  into  performance  attributes 
of  type  6  and  6'  for  these  Alphas. 

Step  2.  If  the  performance  requirement  states  that  the  program  is  executed  with 

resource  utilization  restrictions  between  two  validation  points,  then 
identify  the  modules  corresponding  to  the  "Alphas"  on  the  R-Net 
between  the  validation  points.  For  each  of  these  modules,  designate 
PA. 7  for  the  resource  being  restricted  to  be  a  performance  attribute 
for  the  module.  For  each  of  the  segments  of  code  identified,  desig¬ 
nate  PA. 7'  to  be  a  performance  attribute  for  the  segment.  Decompose 
the  performance  requirement  into  these  performance  attributes  7 
and  7'. 

As  requirement  statement  languages  continue  to  develop,  it  appears 
feasible  that  the  decomposition  of  performance  requirements  into  performance 
attributes  may  be  accomplished  automatically.  If  the  performance  requirements 
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are  not  stated  at  the  R-Net  level,  then  the  decomposition  of  the  performance 
requirements  into  the  performance  attributes  is  more  complex.  The  decomposi¬ 
tion  requires  an  analysis  of  the  modules  whose  execution  is  governed  by  the 
performance  requirements.  Appropriate  performance  attributes  for  these 
modules  must  then  be  identified.  This  process  will  be  more  difficult  to 
automate  than  the  process  of  decomposing  performance  requirements  stated  at 
the  R-Net  level  into  performance  attributes.  Thus,  although  this  mainte¬ 
nance  technique  is  flexible  enough  to  support  the  maintenance  activity  of 
all  software  systems,  the  ideal  situation  occurs  when  performance  require¬ 
ments  are  stated  at  the  R-Net  level. 

Figure  18  is  an  expansion  of  Figure  16  which  includes  a  description  of 
the  relationship  of  performance  requirements,  performance  attributes,  criti¬ 
cal  sections,  and  the  mechanisms  for  the  propagation  of  performance  changes 
in  a  program.  In  this  figure,  the  directed  line  labeled  with  a  mechanism 
connecting  two  performance  attributes  indicates  a  performance  dependency 
relationship  exists  between  the  performance  attributes.  A  directed  line 
also  connects  each  critical  section  with  its  corresponding  performance  attri¬ 
butes.  A  dotted  line  is  used  to  connect  each  performance  attribute  with  a 
performance  requirement  which  may  be  affected  if  the  performance  attribute 
is  changed. 

8.1.2  Algorithm  to  Identify  All  of  the  Mechanisms  for  the  Propagation  of 
Performance  Changes  Present  in  the  Program 

An  important  step  of  the  maintenance  technique  to  be  described  in 
Section  8.2  is  the  identification  of  all  of  the  mechanisms  for  the  propaga¬ 
tion  of  performance  changes  present  in  the  program.  The  algorithm  described 
in  this  section  identifies  all  of  these  mechanisms  by  invoking  the  algorithms 
for  identifying  each  of  these  mechanisms  described  in  Section  3. 

Algorithm  8.1.2.  Identification  of  the  mechanisms  for  the  propagation  of 
performance  changes  present  in  the  program. 

Step  1 .  Apply  Algorithm  3.1.1  to  identify  all  sets  of  modules  that  are 
executable 'in  parallel  with  a  given  module. 

Step  2.  Apply  Algorithm  3.1.5  to  identify  the  parallel  execution  sets  for 
the  program. 

Step  3.  Apply  Algorithm  3.2.1  to  identify  the  shared  resource  mechanism. 
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Figure  18.  An  example  for  illustrating  a  possible  relationship 
among  performance  requirements  (P.R.),  performance 
attributes  (P.A.),  critical  ections  (C.S.)  and  the 
mechanisms  for  propagation  o  performance  changes 
in  a  program. 
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Theorem  8.1,2.  Algorithm  8.1.2  identifies  all  of  the  mechanisms  for  the 
propagation  of  performance  changes  present  in  the  program. 


Proof;  Algorithm  8.1.2  simply  consists  of  invocations  to  Algorithms  3.1.1, 
3.1.5,  3.2„1,  3.3.1,  3.4.1,  3.5.1,  3.6.1,  3.7.1,  and  3.8.1.  Now  each  of 
these  algorithms  identifies  a  particular  mechanism  for  the  propagation  of 
performance  changes  as  proven  in  Theorems  3.1.3,  3.1.7,  3.2.3,  3.3.3,  3.4.3, 
3.5.2,  3.6.2,  3.7.3,  and  3.8.3.  Therefore,  Algorithm  8.1.2  identifies  all 
of  the  mechanisms  for  the  propagation  of  performance  changes  present  in  the 
program. 


8.1.3  Algorithm  to  Identify  All  of  the  Critical  Sections  in  the  Program 
An  important  step  of  the  maintenance  technique  to  be  described  in 
Section  8.2  is  the  identification  of  all  of  the  critical  sections  in  the 
program.  The  algorithm  described  in  this  section  identifies  all  of  these 
critical  sections  by  invoking  the  algorithms  for  identifying  each  critical 
section  of  a  particular  type  described  in  Section  4. 

Algorithm  8.1.3.  Identification  of  all  of  the  critical  sections  in  the 
program. 
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Theorem  8.1.3.  Algorithm  8.1.3  identifies  all  of  the  critical  sections 
which  are  present  in  the  program. 

Proof;  Algorithm  8.1.3  simply  consists  of  invocations  of  Algorithms  4.1  to 
4.7.  Now  each  of  the  Algorithms  4.1  to  4.7  identifies  a  particular  type  of 
critical  section  present  in  the  program  as  proven  in  Theorems  4.1  to  4.7. 
Therefore,  Algorithm  8.1.3  identifies  all  of  the  critical  sections  present 
in  the  program. 

8.1.4  Algorithm  to  Identify  All  of  the  Performance  Attributes  in  the  Program 
An  important  step  of  the  maintenance  technique  to  be  described  in 
Section  8.2  is  the  identification  of  all  of  the  performance  attributes  in 
the  program  described  by  the  mechanisms  for  the  propagation  of  performance 
changes. 

Algorithm  8.1.4.  Identification  of  all  of  the  performance  attributes  in  the 
program  described  by  the  mechanisms  for  the  propagation  of  performance 
changes. 


Step  1. 


Step  2. 

Step  3. 


Step  4. 

Step  5. 


For  each  module  in  the  program  and  each  critical  section  in  the 
module's  characterization,  designate  the  corresponding  performance 
attribute  for  the  critical  section  to  be  a  performance  attribute 
for  the  module. 

For  each  module  in  the  program,  designate  performance  attribute  4 
to  be  a  performance  attribute  for  the  module. 

For  each  resource  i  and  each  module  in  T^  identified  in  Algorithm 
3.2.1  designate  performance  attribute  7  for  resource  i  to  be  a 
performance  attribute  for  the  module. 

For  each  data  structure,  designate  performance  attributes  8,  9,  and 
10  to  be  performance  attributes  for  the  data  structure. 

For  each  module  in  the  program  which  interfaces  with  the  environment 
to  handle  input  interrupts,  designate  performance  attribute  11 
to  be  a  performance  attribute  for  the  module. 


Theorem  8.1.4.  Algorithm  8.1.4  identifies  all  of  the  performance  attributes 
in  the  program  described  by  the  mechanisms  for  the  propagation  of  performance 
changes. 
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Proof ;  The  performance  attributes  were  defined  in  terms  of  the  mechanisms 
for  the  propagation  of  performance  changes.  Critical  software  sections  were 
defined  for  performance  attributes  1,  2,  3,  5,  6,  7  and  12.  Step  1  of  the 
algorithm  simply  designates  the  corresponding  performance  attributes  for  the 
critical  sections  to  be  performance  attributes  for  the  modules  containing  the 
critical  sections.  Now  performance  attributes  4,  8,  9,  10  and  11  do  not 
possess  critical  sections.  These  performance  attributes  are  identified  by 
Steps  2,  4  and  5  of  the  algorithm  by  definition  of  the  performance  attributes 
in  terms  of  the  mechanisms  for  the  propagation  of  performance  changes. 

Finally,  Step  3  of  the  algorithm  identifies  performance  attribute  7  for  those 
modules  that  do  not  directly  reference  the  resource,  but  invoke  a  module  which 
does  utilize  the  resource  by  definition  of  performance  attribute  7  in  terms 
of  the  mechanisms  for  the  propagation  of  performance  changes. 

Therefore,  all  of  the  performance  attributes  in  the  program  described 
by  the  mechanisms  for  the  propagation  of  performance  changes  are  identified. 


8.1.5  Algorithm  to  Identify  All  of  the  Virtual  Performance  Attributes  in  a 


Program 

An  important  step  of  the  maintenance  technique  to  be  described  in 
Section  8.2  is  the  identification  of  all  of  the  virtual  performance  attri¬ 
butes  in  the  program. 


Step  1.  For  each  module  involved  in  a  PIR  via  mechanism  2  and  each  state¬ 
ment  in  the  module  which  requests  the  resource  in  contention, 
designate  virtual  performance  attribute  of  type  one  for  the  con¬ 
tended  resource  to  be  a  virtual  performance  attribute  for  the  module. 

Step  2.  For  each  module  in  the  program  and  each  statement  in  the  module 

which  invoked  another  module  or  an  abstraction,  designate  virtual 
performance  attribute  of  type  two  for  the  module  or  abstraction 
invoked  to  be  a  virtual  performance  attribute  for  the  module  invoking 
them. 

Step  3.  For  each  module  in  the  program  and  each  dependent  iterative  structure 
in  the  module,  designate  virtual  performance  attribute  of  type  three 
for  the  dependent  iterative  structure  to  be  a  virtual  performance 
attribute  for  the  module. 
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Step  4.  For  each  module  in  the  program  utilizing  a  data  structure  and  each 
statement  in  the  module  which  references  the  data  structure,  desig¬ 
nate  virtual  performance  attribute  of  type  four  for  the  data  struc¬ 
ture  to  be  a  virtual  performance  attribute  for  the  module. 

Step  5.  For  each  dependent  module  involved  in  a  PDR  via  mechanism  3  and 

each  statement  corresponding  to  a  WAIT  for  the  message,  designate 
virtual  performance  attribute  of  type  five  for  the  message  to  be  a 
virtual  performance  attribute  for  the  module. 

Theorem  8.1.5.  Algorithm  8.1.5  identifies  all  of  the  virtual  performance 
attributes  in  a  program. 

Proof:  The  proof  of  the  theorem  follows  directly  from  the  definition  of 
firtual  performance  attributes  of  types  one,  two,  three,  four  and  five.  Each 
of  the  steps  of  the  algorithm  identifies  a  virtual  performance  attribute 
according  to  the  definition  of  the  virtual  performance  attributes. 

8.2  Formal  Description  of  the  Maintenance  Technique 

In  this  section,  a  maintenance  technique  for  predicting  which  perfor¬ 
mance  requirements  are  affected  by  program  modifications  will  be  formally 
described.  The  maintenance  technique  consists  of  two  stages.  The  first 
stage  consists  of  a  lexical  analysis  of  the  program  with  respect  to  the 
proposed  modification.  In  this  stage,  the  program  is  analyzed  with  respect 
to  the  proposed  modification,  and  the  performance  characterization  of  the 
program  is  compiled  and  saved  in  a  data  base.  This  characterization  is  then 
utilized  in  the  second  stage  of  the  maintenance  technique.  The  second  stage 
consists  of  tracing  the  performance  changes,  i.e.,  the  performance  ripple 
effect  which  occurs  as  a  consequence  of  the  maintenance  changes. 

8.2.1  Lexical  Analysis  Stage  of  the  Maintenance  Technique 

Step  1.  Decompose  the  performance  requirements  for  the  program  into  the 
performance  attributes  which  contribute  to  the  preservation  or 
violation  of  the  performance  requirements.  Some  guidelines  for 
this  decomposition  are  presented  in  Section  8.1.1. 

Step  2.  Apply  Algorithm  8.1.2  to  identify  all  of  the  mechanisms  for  the 
propagation  of  performance  changes  present  in  the  program. 
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Step  3.  Apply  Algorithm  8.1.3  to  identify  all  of  the  critical  sections  in 
the  program. 

Step  4.  Apply  Algorithm  8.1.4  to  identify  all  of  the  performance  attributes 
in  the  program. 

Step  5.  Apply  Algorithm  8.1.5  to  identify  all  of  the  virtual  performance 
attributes  in  the  program. 

8.2.2  Algorithm  to  Trace  the  Ripple  Effect  of  Performance  Changes  Among 
the  Performance  Attributes 

The  second  stage  of  the  maintenance  technique  to  be  described  in 
Section  8.2.3  consists  of  tracing  the  performance  changes  which  occur  as  a 
consequence  of  the  program  modification.  An  important  step  of  this  stage 
is  the  ability  to  trace  the  ripple  effect  of  performance  changes  among  the 
performance  attributes.  In  this  section,  an  algorithm  will  be  described  to 
accomplish  this  objective.  The  proof  of  this  algorithm  will  be  presented 
in  Section  8.3  along  with  other  major  proofs  of  the  algorithms  composing 
the  maintenance  technique. 

Algorithm  8.2.2.  Identification  of  all  of  the  performance  attributes  in  a 
program  which  has  been  analyzed  by  the  first  stage  of  the  maintenance  techni¬ 
que  described  in  Section  8.2.1  which  may  be  affected  as  a  consequence  of 
modifying  the  performance  attributes  which  are  contained  in  set  X. 

Step  1.  Select  an  element,  x,  in  X  which  has  not  been  selected  before.  If 
there  are  no  new  elements  in  X  to  select,  then  terminate. 

Step  2.  Utilizing  the  rules  describing  the  performance  dependency  relation¬ 
ships  among  the  performance  attributes  summarized  in  Section  6, 
identify  all  of  the  performance  attributes  in  the  program  which  may 
be  affected  by  a  modification  of  performance  attribute  x.  Add  these 
new  performance  attributes  to  X  if  they  do  not  already  appear. 

Step  3.  Utilizing  the  rules  describing  the  performance  dependency  relation¬ 
ships  between  the  performance  attributes  and  the  virtual  performance 
attributes  summarized  in  Section  6,  identify  all  of  the  virtual 
performance  attributes  in  the  program  which  may  be  affected  by  a 
modification  of  performance  attribute  x.  If  x  does  not  affect  any 
virtual  performance  attributes,  go  to  Step  5,  else  go  to  Step  4. 
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Step  4.  For  each  of  the  virtual  performance  attributes  identified  for  x  in 
Step  3,  apply  one  of  algorithms  5.1  to  5.5  depending  upon  the  type 
of  virtual  performance  attribute  identified,  to  identify  all  of  the 
performance  attributes  affected  by  modification  of  the  virtual  per¬ 
formance  attribute  identified  in  Step  3.  Add  these  new  performance 
attributes  to  X  if  they  do  not  already  appear. 


The  second  stage  of  the  maintenance  technique  consists  of  tracing  the 
performance  changes,  i.e.,  the  performance  ripple  effect  which  occurs  as  a 
consequence  of  the  maintenance  changes.  The  input  to  the  technique  in  this 
stage  includes  all  of  the  information  about  the  program  collected  and  stored 
in  a  data  base  during  the  lexical  analysis  stage.  The  second  stage  of  the 
maintenance  technique  identifies  the  performance  requirements  which  are 
affected  by  the  proposed  program  modification.  This  second  stage  consists 
of  the  following  steps: 

Step  1.  Identify  the  critical  sections  which  may  be  affected  by  the  mainte¬ 
nance  activity.  The  critical  sections  of  the  program  were  identified 
in  Step  3  of  Stage  1. 

Step  2.  For  each  of  the  critical  sections  identified  in  Step  1,  determine 
the  corresponding  performance  attributes  which  may  be  affected  if 
the  critical  section  is  modified.  The  correspondence  between  criti¬ 
cal  sections  and  performance  attributes  was  established  in  Section  4. 
Let  X  be  the  set  of  these  performance  attributes. 

Step  3.  Apply  Algorithm  8.2.2  to  identify  all  of  the  performance  attributes 
which  may  be  affected  as  a  consequence  of  modifying  the  performance 
attributes  contained  in  set  X.  Let  X  contain  the  set  of  all  of 
these  performance  attributes. 

Step  4.  Identify  those  performance  requirements  which  are  affected  by  a 

modification  of  the  performance  attributes  in  set  X.  These  perfor¬ 
mance  requirements  can  be  identified  by  the  traceability  of  the 
decomposition  of  the  performance  requirements  into  the  performance 
attributes  in  Step  1  of  Stage  1. 


The  important  steps  of  this  maintenance  technique  are  summarized  and 
put  into  perspective  within  the  maintenance  process  in  Figure  19.  From  the 
example  shown  in  Figure  18,  the  maintenance  technique  could  be  used  to  pre¬ 
dict  the  performance  implications  of  modifying  CS.l  of  Process  A.  In  this 
example,  PA.l  and  PA. 2  of  Process  A  would  be  affected.  Thus,  performance 
requirements  PR.l  and  PR. 2  would  have  to  be  retested  to  insure  that  they 
have  not  been  violated.  In  addition,  PA.l  of  Process  B  would  be  affected 
via  mechanism  1.  Thus,  PR..  4  would  also  have  to  be  retested  to  insure  that 
it  too  has  not  been  violated. 

8.3  Proof  of  Algorithms  Composing  the  Maintenance  Technique 

The  maintenance  technique  described  in  Section  8.2  is  very  generalized 
and  flexible  in  nature.  Additional  mechanisms,  performance  attributes, 
virtual  performance  attributes,  critical  sections  and  performance  dependency 
relationship  rules  can  easily  be  added  to  the  maintenance  technique  to  enable 
it  to  be  applicable  to  any  program.  In  this  manner,  the  technique  can  be 
utilized  to  maintain  any  program.  In  this  section,  the  remaining  algorithms 
composing  the  maintenance  technique  will  be  proved  to  be  correct. 

8.3.1  Proof  of  the  Algorithms  Composing  Stage  One  of  the  Maintenance  Techni¬ 
que 

In  this  section,  the  algorithms  composing  stage  one  of  the  maintenance 
technique  will  be  proven  correct. 

Theorem  8.3.1.  The  first  stage  of  the  maintenance  technique  described  in 
Section  8.2.1  identifies  all  of  the  mechanisms  for  the  propagation  of  per¬ 
formance  changes,  critical  sections,  performance  attributes  and  virtual 
performance  attributes  in  the  program. 

Proof;  Step  2  of  Stage  One  of  the  maintenance  technique  invokes  Algorithm 

8.1.2  to  identify  the  eight  mechanisms  for  the  propagation  of  performance 
changes  defined  in  Section  3.  Theorem  8.1.2  proves  that  all  eight  of  these 
mechanisms  are  identified  by  Algorithm  8.1.2.  Thus,  the  first  stage  of  the 
maintenance  technique  identifies  all  of  the  mechanisms  for  the  propagation 
of  performance  changes  in  the  program. 

Step  3  of  Stage  One  of  the  maintenance  technique  invokes  Algorithm 

8.1.3  to  identify  all  of  the  critical  sections  in  the  program.  Theorem  8.1.3 
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maintenance  personnel  generate  a  number  of  program 

MODIFICATION  PROPOSALS 

1 

SELECT  ONE  MODIFICATION  PROPOSAL  TO  EVALUATE  ITS 
RIPPLE  EFFECT 

\ 

CRITICAL  SECTIONS  AFFECTED  BY  THE  MODIFICATION 
ARE  IDENTIFIED 

I 

PERFORMANCE  ATTRIBUTES  AFFECTED  BY  CHANGES  TO  THESE 
CRITICAL  SOFTWARE  SECTIONS  ARE  IDENTIFIED 

I 

THE  EFFECT  OF  CHANGING  THESE  PERFORMANCE  ATTRIBUTES 
IS  TRACED  THROUGHOUT  THE  PROGRAM  TO  IDENTIFY  ALL 
PERFORMANCE  ATTRIBUTES  WHICH  MAY  BE  AFFECTED 

I 

PERFORMANCE  REQUIREMENTS  WHICH  MAY  BE  VIOLATED  BY 
THE  PROPOSED  MODIFICATION  ARE  IDENTIFIED 


MAINTENANCE  PERSONNEL  DETERMINE  WHETHER  THE  SELECTED 
MAINTENANCE  PROPOSAL  IS  SUITABLE  FOR  THE  PROGRAM 
CONSIDERING  BOTH  FUNCTIONAL  AND  PERFORMANCE 
IMPLICATIONS  OF  THE  PROPOSED  MODIFICATION 


Figure  19.  The  framework  of  the  performance  ripple 
effect  analysis  technique  for  predicting 
which  performance  requirements  are 
affected  by  the  maintenance  activity. 
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proves  that  all  of  the  critical  sections  are  identified  by  Algorithm  8.1.3. 
Thus,  the  first  stage  of  the  maintenance  technique  identifies  all  of  the 
critical  sections  in  the  program. 

Step  4  of  Stage  One  of  the  maintenance  technique  invokes  Algorithm  8.1.4 
to  identify  all  of  the  performance  attributes  in  the  program.  Theorem  8.1.4 
proves  that  all  of  the  performance  attributes  are  identified  by  Algorithm 
8.1.4.  Thus,  the  first  stage  of  the  maintenance  technique  identifies  all 
of  the  performance  attributes  in  the  program. 

Step  5  of  Stage  One  of  the  maintenance  technique  invokes  Algorithm  8.1.5 
to  identify  all  of  the  virtual  performance  attributes  in  the  program. 

Theorem  8.1.5  proves  that  all  of  the  virtual  performance  attributes  are 
identified  by  Algorithm  8.1.5.  Thus,  the  first  stage  of  the  maintenance 
technique  identifies  all  of  the  virtual  performance  attributes  in  the  program. 

Therefore,  the  first  stage  of  the  maintenance  technique  identifies  all 
of  the  mechanisms  for  the  propagation  of  performance  changes,  critical 
sections,  performance  attributes  and  virtual  performance  attributes  in  the 
program. 

8.3.2  Theorem  for  Algorithm  8.2.2 

In  this  section,  a  proof  of  the  correctness  of  Algorithm  8.2.2  will  be 
presented.  This  algorithm  is  responsible  for  tracing  the  ripple  effect  of 
performance  changes  among  the  performance  attributes. 

Theorem  8.3.2.  Algorithm  8.2.2  identifies  all  of  the  performance  attributes 
in  a  program  which  has  been  analyzed  by  the  first  stage  of  the  maintenance 
technique  described  in  Section  8.2.1,  which  may  be  affected  as  a  consequence 
of  modifying  the  performance  attributes  which  are  contained  in  set  X. 

Proof;  Let  x  be  an  arbitrary  element  of  X.  It  must  be  shown  that  all  per¬ 
formance  attributes  which  may  be  affected  as  a  consequence  of  modifying  x 
are  added  to  set  X  by  the  algorithm.  Let  y  be  an  arbitrary  performance 
attribute  which  may  be  affected  as  a  consequence  of  modifying  x.  It  must  be 
shown  that  y  6  X. 

Now  since  the  program  has  been  analyzed  by  the  first  stage  of  the  main¬ 
tenance  technique.  Theorem  8.3.1  guarantees  that  all  of  the  mechanisms  for 
the  propagation  of  performance  changes,  performance  attributes  and  virtual 
performance  attributes  in  the  program  have  been  identified.  With  this 
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information,  all  of  the  performance  dependency  relationships  between  perfor¬ 
mance  attributes  and  virtual  performance  attributes  can  be  determined  by  the 
defined  rules  which  are  summarized  in  Sections  5  and  6.  The  proof  requires 
consideration  of  three  cases. 


Case  1.  Assume  there  exists  a  rule  summarized  in  Section  6.0  which  describes 
a  performance  dependency  relationship  between  performance  attributes  x  and  y. 
Then,  Step  2  of  the  algorithm  adds  y  to  X. 

Case  2.  Assume  there  exists  a  performance  dependency  relationship  between 
a  virtual  performance  attribute  z  and  performance  attribute  y  and  that  there 
exists  a  rule  summarized  in  Section  6  which  describes  a  performance  depen¬ 
dency  relationship  between  performance  attribute  x  and  virtual  performance 
attribute  z.  Then,  Steps  3  and  4  of  the  algorithm  add  y  to  X. 

Case  3.  Assuming  that  neither  case  1  nor  case  2  is  true,  the  fact  that  y 
may  be  affected  as  a  consequence  of  modifying  x  implies  there  exists  perfor¬ 
mance  attributes  x,  x^,  X2, ... ,x^,y,  where  x  affects  x^,  x 
affects  y  via  either  a  rule  summarized  in  Section  6  or  a  performance  depen¬ 
dency  relationship  involving  virtual  performance  attributes  described  in 
Section  5.  In  either  case.  Steps  1,  2,  3,  4  and  5  add  x^ ,X2 , . . . ,x^ ,y  to 
set  X. 

♦Therefore,  all  performance  attributes  which  may  be  affected  as  a  conse¬ 
quence  of  modifying  x  are  added  to  set  X. 


1  affects  X2, 


’’Sc 


8.3.3  Proof  of  the  Second  Stage  of  the  Maintenance  Technique 

The  second  stage  of  the  maintenance  technique  described  in  Section  8.2.3 
predicts  which  performance  requirements  are  affected  by  a  proposed  program 
modification.  This  is  accomplished  by  tracing  the  ripple  effect  of  perfor¬ 
mance  changes  among  the  performance  attributes.  In  this  section  a  proof  will 
be  provided  that  this  second  stage  of  the  maintenance  technique  accomplishes 
this  objective. 

Theorem  8,3.3.  The  second  stage  of  the  maintenance  technique  described  in 
Section  8.2.3  identifies  the  performance  requirements  affected  in  a  program 
based  upon  the  performance  characterization  produced  by  the  first  stage  of 
the  maintenance  technique  which  may  be  affected  by  a  proposed  modification. 
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Proof:  Theorem  8.3.1  guarantees  that  all  of  the  critical  sectiohs  in  the 
program  were  identified  in  the  first  stage  of  the  maintenance  technique. 

Step  1  of  Stage  Two  of  the  maintenance  technique  then  identifies  all  of 
these  critical  sections  which  may  be  affected  by  the  maintenance  activity. 

Theorem  8.3.1  also  guarantees  that  all  of  the  performance  attributes  in 
the  program  were  identified  in  the  first  stage  of  the  maintenance  technique. 
Step  2  of  Stage  Two  of  the  maintenance  technique  then  identifies  all  of  the 
performance  attributes  which  correspond  to  the  critical  sections  identifed 
in  Step  1  of  Stage  Two  of  the  maintenance  technique.  This  correspondence 
between  performance  attributes  and  critical  sections  was  defined  in  Section  4. 

Step  3  of  Stage  Two  of  the  maintenance  technique  then  invokes  Algorithm 
8.2.2  to  identify  all  of  the  performance  attributes  in  the  program  which  may 
be  affected  as  a  consequence  of  modifying  the  performance  attributes  identi¬ 
fied  in  Step  2  of  Stage  Two  of  the  maintenance  technique.  Theorem  8.3.2 
guarantees  that  all  of  these  performance  attributes  will  be  identified. 

Step  4  of  Stage  Two  of  the  maintenance  technique  then  identifies  all 
of  the  performance  requirements  which  are  affected  by  a  modification  of  the 
performance  attributes  identified  in  Step  3  of  Stage  Two  of  the  maintenance 
technique.  These  performance  requirements  can  be  identified  directly  by  the 
traceability  of  the  decomposition  of  the  performance  requirements  into  the 
performance  attributes  accomplished  in  Step  1  of  Stage  One  of  the  maintenance 
technique. 

Therefore,  the  second  stage  of  the  maintenance  technique  identifies  the 
performance  requirements  which  may  be  affected  by  a  proposed  modification. 

8.4  Application  of  the  Maintenance  Technique  to  the  Retesting  Phase  of  the 

Maintenance  Process 

After  the  maintenance  changes  have  been  completely  implemented,  this 
technique  can  provide  a  significant  contribution  to  the  application  of  retest¬ 
ing  the  program  to  verify  that  the  performance  requirements  for  the  program 
have  not  been  violated  by  the  maintenance  effort.  The  retesting  of  large- 
scale  complex  programs  requires  a  great  deal  of  time,  effort  and  expense. 

Thus,  any  savings  resulting  from  this  maintenance  technique  will  clearly 
justify  its  use. 
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During  the  early  stages  of  the  maintenance  process,  this  technique  was 
utilized  as  an  aid  in  developing  criteria  for  maintenance  personnel  to  evalu¬ 
ate  alternate  program  modifications  from  a  performance  perspective.  Basi¬ 
cally,  this  involved  the  worst-case  identifications  of  performance  require¬ 
ments  which  might  be  affected  by  the  program  modifications.  After  a  program 
modification  has  been  selected  and  completely  implemented,  the  maintenance 
technique  can  substantially  refine  its  analysis  and  determine  more  accurately 
which  performance  requirements  may  have  been  affected  by  the  program  modifi¬ 
cations.  This  is  accomplished  by  determining  whether  or  not  a  performance 
attribute  is  actually  affected  before  implicating  other  performance  attri¬ 
butes  involved  in  a  performance  dependency  relationship  with  the  given  attri¬ 
bute.  In  other  words,  if  a  dependency  relationship  exists  between  perfor¬ 
mance  attributes  1  and  2,  performance  attribute  2  need  not  be  examined 
for  changes  if  it  has  been  determined  that  performance  attribute  1  is  not 
affected  by  the  maintenance  activity.  Thus,  the  preliminary  results  of 
some  of  the  early  retesting  efforts  may  be  decisive  in  the  determination  of 
the  scale  of  retesting  which  remains  to  be  done.  This  technique  is  summar¬ 
ized  and  put  into  perspective  within  the  maintenance  process  in  Figure  20. 

It  should  be  noted  that  if  a  violation  of  a  performance  requirement  occurs, 
it  requires  further  software  maintenance  in  order  to  satisfy  the  performance 
requirement,  and  the  entire  process  must  be  repeated. 

9.0  FIGURE  OF  MERIT  FOR  THE  COMPLEXITY  OF  A  PROGRAM  MODIFICATION 

The  previous  sections  of  this  report  contained  the  development  of  a 
maintenance  technique  for  predicting  which  performance  requirements  in  the 
program  may  be  affected  by  a  proposed  software  modification.  They  also 
illustrated  how  the  maintenance  technique  can  help  retest  the  program  to 
determine  whether  its  performance  requirements  have  been  violated  by  the 
maintenance  effort  after  the  maintenance  changes  have  been  implemented. 

Another  very  significant  product  of  the  analysis  of  ripple  effect  is  the 
computation  of  a  figure -of -merit  for  the  complexity  of  a  proposed  program 
modification.  One  such  figure-of-merit  is  defined  in  [8]  as  follows: 
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Figure  20.  The  performance  ripple  effect  analysis 
technique  as  a  part  of  the  maintenance 
process. 


107 


Complexity  of 
Program  Modification 


Effort  required  to  implement 
change  into  the  program  and 
accommodate  ripple  effect 


This  figure  for  complexity  of  program  modification  is  based  upon  the  effort 
required  to  implement  a  change  into  the  program  and  accommodate  both  its 
functional  and  performance  ripple  effect.  The  figure,  thus,  provides  a 
measure  which  reflects  the  amount  of  work  involved  in  performing  maintenance 
and  provides  a  standard  on  which  comparison  of  modifications  can  be  made. 

A  primitive  estimator  of  the  functional  component  of  this  figure  can  be 
given  as  follows: 

Hj 

where 


Mj  is  a  module  in  the  initial  modification  or  an  element  of  the 
logical  ripple  effect  set. 

Rj  is  the  resistance  of  to  change  [22] 

Analogously,  a  primitive  estimator  of  the  functional  component  of  this 
figure  can  be  defined  as 


where 


Sr 


j 


Mj  is  a  module  in  the  initial  modification  or  an  element  of  the 
set  of  modules  affected  by  performance  ripple  effect. 

Rj  is  the  resistance  of  to  change 

The  resistance  of  a  module  to  change  reflects  the  understandability  of 
the  module  to  the  maintenance  personnel.  The  understandability  of  a  module 
is  a  function  of  several  parameters.  One  of  the  major  parameters  affecting 
understandability  is  structural  complexity  [23],  Thus,  the  primitive  esti¬ 
mator  presented  here  can  be  based  upon  the  structural  complexity  of  the 
modules  involved  in  the  maintenance  effort. 
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10.0  FUTURE  RESEARCH  AND  CONCLUSION 


10.1  Dynamic  Analysis 

The  significance  of  this  performance  ripple  effect  analysis  technique  is  its 
ability  to  trace  repercussions  introduced  by  maintenance  changes  and  predict 
which  performance  requirements  may  be  affected  by  the  program  modifications. 
This  information  is  very  valuable  to  maintenance  personnel  but  its  signifi¬ 
cance  can  be  even  greater  if  it  is  supplemented  by  a  profile  of  the  dynamic 
behavior  of  the  program.  This  profile  can  provide  maintenance  personnel 
with  performance  information  about  the  program  enabling  them  to  identify 
performance  requirements  which  are  close  to  being  violated.  This  information 
coupled  with  that  predicting  which  performance  requirements  may  be  affected 
by  a  program  modification  provides  maintenance  personnel  with  strong  guide¬ 
lines  for  selecting  among  alternative  program  modifications. 

The  profile  of  the  dynamic  behavior  of  a  program  also  plays  a  signifi¬ 
cant  role  in  the  retesting  portion  of  the  maintenance  phase  to  insure  that 
the  program  modifications  have  not  resulted  in  violation  of  any  performance 
requirements.  After  the  maintenance  modifications  have  been  implemented 
and  the  resultant  changes  in  performance  analyzed,  this  information  can  be 
used  along  with  the  profile  of  the  dynamic  behavior  of  the  program  to  deter¬ 
mine  the  scale  of  retesting  which  remains  to  be  done.  For  example,  if  a 
process  has  a  performance  requirement  stating  that  it  completes  execution  in 
100  units,  it  will  not  be  affected  by  a  performance  change  of  about  5  units 
if  the  program's  profile  indicates  it  is  currently  completing  execution  in 
75  units. 

The  profile  of  the  dynamic  behavior  of  the  program  is,  thus,  important 
in  the  maintenance  phase.  It  should  be  noted  that  the  profile  itself  is 
dynamic  since  it  only  reflects  the  dynamic  behavior  in  the  current  environ¬ 
ment.  Nevertheless,  it  is  important  in  performance  investigations  since  the 
performance  of  the  program  is  also  dependent  of  the  current  environment.  It 
is,  thus,  meaningless  to  analyze  performance  considerations  utilizing  a  pro¬ 
file  based  upon  a  different  operating  environment. 

More  research  is  needed  in  the  identification  of  appropriate  dynamic 
measurements  to  be  included  in  this  profile.  It  is  seen  from  previous  sec¬ 
tions  that  measurements  pertaining  to  resource  utilization,  execution  times 
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of  critical  software  sections,  system  overhead,  and  degree  of  saturation  of 
data  structures  provide  the  most  meaningful  information  for  the  maintenance 
process.  The  feasibility  of  collecting  many  of  these  measurements  in  large- 
scale  software  systems  has  already  been  demonstrated."  For  example,  JAVS 
provides  a  facility  for  capturing  the  execution  time  spent  in  individual 
modules  [24],  The  Program  Evaluator  and  Test  System  developed  by  Stuck!  [25] 
also  provides  relative  timing  on  the  subroutine  level.  System  overhead  has 
also  been  studied  for  some  time,  and  both  hardware  and  software  measuring 
techniques  exist  to  identify  many  of  its  sources.  Measurements  pertaining  to 
resource  utilization,  such  as  data  structures,  have  also  been  recorded  using 
software  probes  [26] .  Data  pertaining  to  the  time  when  a  resource  is  requested 
and  when  that  request  is  actually  satisfied  has  been  collected  on  large- 
scale  software  systems  with  a  degradation  of  system  performance  due  to 
resources  committed  to  probe  operation  not  exceeding  57».  For  example  , 

Figure  21  illustrates  the  types  of  measurements  that  can  be  gathered  for  an 
executing  process.  In  the  figure,  execution  times  between  requests  as  well 
as  probabilities  that  particular  branches  from  decision  nodes  are  executed 
appear  in  the  graph  [27].  These  types  of  measurements  would  be  important  in 
formulating  the  profile  of  the  dynamic  behavior  of  the  program  most  applicable 
to  the  maintenance  process.  More  research  is  needed  in  the  identification  of 
other  appropriate  dynamic  measurements  to  be  included  in  this  profile. 


In  section  9  a  primitive  estimator  of  the  performance  component  of  a 


figure  for  the  complexity  of  a  proposed  program  modification  was  described. 
This  estimator  was  based  upon  the  performance  ripple  effect  of  the  proposed 
modification  and  the  structural  complexity  of  the  modules  involved  in  the 
maintenance  effort.  This  figure  can  be  enhanced  by  the  addition  of  other 
factors  which  contribute  to  the  complexity  of  program  modification  from  a 
performance  perspective. 

One  such  factor  involves  the  profile  of  the  dynamic  behavior  of  the 
program.  The  performance  of  a  program  is  a  subject  which  ranges  from 
quantitative  analyses  to  qualitative  judgements  [28],  Thus,  the  current 
behavior  of  the  program  in  perspective  to  its  performance  requirements  can 
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Figure  21.  A  directed  graph  representing  resource 
utilization  of  a  process. 


provide  insight  into  the  degree  of  performance  changes  that  can  be  tolerated 
without  a  performance  requirement  violation.  For  example,  if  the  program  is 
operating  near  a  point  of  saturation,  any  performance  changes  could  lead  to 
performance  requirement  violations.  Thus,  a  modification  to  a  program  which 
is  close  to  violating  some  of  its  performance  requirements  will  require  a 
more  complex  modification  than  a  program  which  is  not  close  to  violating  any 
of  its  performance  requirements.  More  research  is  needed  in  this  area  to 
identify  additional  factors  which  contribute  to  the  complexity  of  program 
modification  from  a  performance  perspective  and  integrate  these  factors  into 
a  meaningful  figure -of -merit. 

10.3  Application  to  Design  Phase 

One  of  the  most  serious  problems  in  software  development  is  the  lack  of 
methodologies  to  evaluate  a  software  design  before,  or  even  after,  it  is 
implemented.  When  several  alternatives  are  available,  the  design  decision 
is  made  quite  arbitrarily  based  on  intuition.  An  elegant  design  of  a  system 
depends  on  many  parameters:  logical  organization,  maintainability,  compact¬ 
ness,  efficiency,  extendability,  etc.  However,  the  most  important  considera¬ 
tion  to  reduce  cost  and  to  improve  reliability  is  the  maintainability  of  the 
system.  For  a  large  software  system  with  a  long  lifetime,  the  cost  of  main¬ 
taining  the  system  may  very  well  exceed  the  cost  of  developing  the  system  for 
delivery.  Maintaining  a  large  program  will  also  affect  its  reliability  by 
unconsciously  introducing  undesirable  side-effects  while  making  a  modification 
in  the  program.  Thus,  quantitative  measures  of  program  maintainability  are 
needed  to  evaluate  software  designs  both  before  and  after  they  are  implemented 

One  quantitative  measure  of  program  maintainability  is  the  extent  that 
a  program  is  affected  by  a  modification.  The  research  results  obtained  in 
the  analysis  of  logical  and  performance  ripple  effect  provide  an  excellent 
foundation  for  research  into  identifying  significant  software  quality  factors 
that  contribute  towards  this  measure.  Once  these  software  quality  factors 
that  affect  maintainability  are  identified,  software  design  methodologies 
can  be  analyzed  to  determine  their  effectiveness  in  producing  maintainable 
software.  The  results  of  this  investigation  may  lead  to  the  development  of 
a  new  software  design  methodology  which  produces  programs  with  good  mainte¬ 
nance  characteristics. 
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10.4  Conclusion 

The  process  of  developing  complex  large  scale  software  systems  possess¬ 
ing  performance  requirements  is  costly,  excessively  time-consuming,  and 
difficult  to  manage.  This  process  frequently  leads  to  systems  which  are 
unreliable,  not  responsive  to  user-requirements,  and  logically  too  obscure  to 
be  readily  analyzed  or  maintained.  Yet  these  software  systems  must  be  main¬ 
tained,  and  the  magnitude  of  this  maintenance  in  terms  of  the  total  software 
effort  is  very  large.  Some  projections  indicate  that  the  magnitude  of  this 
maintenance  cost  may  ultimately  result  in  a  five  or  ten  to  one  ratio  of 
maintenance  costs  to  research  ard  development  costs  when  viewed  over  the 
total  life  cycle  of  a  typical  sj stem  [29].  Thus,  maintenance  techniques  are 
needed  that  are  specifically  dejigned  to  predict  the  effect  of  software  modi¬ 
fications  and  indicate  test  cases  required  for  program  retesting.  The  main¬ 
tenance  technique  presented  in  this  report  is  designed  with  these  objectives 
in  mind  and  should  significantly  aid  maintenance  personnel  in  maintaining 
software  systems. 
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